aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/TargetLibraryInfo.cpp
AgeCommit message (Collapse)AuthorFilesLines
2020-07-18[LLVM] Add libatomic load/store functions to TargetLibraryInfoGui Andrade1-0/+9
This allows treating these functions like libcalls. This patch is a prerequisite to instrumenting them in MSAN: https://reviews.llvm.org/D83337 Differential Revision: https://reviews.llvm.org/D83361
2020-06-16[TLI] Add four C++17 delete variants.Hiroshi Yamauchi1-0/+8
Summary: delete(void*, unsigned int, align_val_t) delete(void*, unsigned long, align_val_t) delete[](void*, unsigned int, align_val_t) delete[](void*, unsigned long, align_val_t) Differential Revision: https://reviews.llvm.org/D81853
2020-05-26[FPEnv] Intrinsic llvm.roundevenSerge Pavlov1-0/+3
This intrinsic implements IEEE-754 operation roundToIntegralTiesToEven, and performs rounding to the nearest integer value, rounding halfway cases to even. The intrinsic represents the missed case of IEEE-754 rounding operations and now llvm provides full support of the rounding operations defined by the standard. Differential Revision: https://reviews.llvm.org/D75670
2020-04-14[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers.Georgii Rymar1-5/+4
It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappers we already have. Differential revision: https://reviews.llvm.org/D78016
2020-04-11Revert "[TLI] Per-function fveclib for math library used for vectorization"Mehdi Amini1-70/+21
This reverts commit 60c642e74be6af86906d9f3d982728be7bd4329f. This patch is making the TLI "closed" for a predefined set of VecLib while at the moment it is extensible for anyone to customize when using LLVM as a library. Reverting while we figure out a way to re-land it without losing the generality of the current API. Differential Revision: https://reviews.llvm.org/D77925
2020-04-09[TLI] Per-function fveclib for math library used for vectorizationWenlei He1-21/+70
Summary: Encode `-fveclib` setting as per-function attribute so it can threaded through to LTO backends. Accordingly per-function TLI now reads the attributes and select available vector function list based on that. Now we also populate function list for all supported vector libraries for the shared per-module `TargetLibraryInfoImpl`, so each function can select its available vector list independently but without duplicating the vector function lists. Inlining between incompatbile vectlib attributed is also prohibited now. Subscribers: hiraditya, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77632
2020-03-29Introduce support for lib function aligned_alloc in TLI / memory builtinsUday Bondhugula1-0/+2
Aligned_alloc is a standard lib function and has been in glibc since 2.16 and in the C11 standard. It has semantics similar to malloc/calloc for several analyses/transforms. This patch introduces aligned_alloc in target library info and memory builtins. Subsequent ones will make other passes aware and fix https://bugs.llvm.org/show_bug.cgi?id=44062 This change will also be useful to LLVM generators that need to allocate buffers of vector elements larger than 16 bytes (for eg. 256-bit ones), element boundary alignment for which is not typically provided by glibc malloc. Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Differential Revision: https://reviews.llvm.org/D76970
2020-03-22Add Triple::isAMDGPUYaxun (Sam) Liu1-4/+2
Differential Revision: https://reviews.llvm.org/D57707
2020-02-28No longer generate calls to *_finiteserge-sans-paille1-0/+3
According to Joseph Myers, a libm maintainer > They were only ever an ABI (selected by use of -ffinite-math-only or > options implying it, which resulted in the headers using "asm" to redirect > calls to some libm functions), not an API. The change means that ABI has > turned into compat symbols (only available for existing binaries, not for > anything newly linked, not included in static libm at all, not included in > shared libm for future glibc ports such as RV32), so, yes, in any case > where tools generate direct calls to those functions (rather than just > following the "asm" annotations on function declarations in the headers), > they need to stop doing so. As a consequence, we should no longer assume these symbols are available on the target system. Still keep the TargetLibraryInfo for constant folding. Differential Revision: https://reviews.llvm.org/D74712
2020-02-18[NFC] Remove trailing spaceJim Lin1-2/+2
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h,td}
2020-02-12[ConstantFolding] Fold calls to FP remainder functionEhud Katz1-0/+5
With the fixed implementation of the "remainder" operation in rG9d0956ebd471, we can now add support to folding calls to it. Differential Revision: https://reviews.llvm.org/D69777
2020-02-08[SimplifyLibCalls] Add __strlen_chk.George Burgess IV1-0/+5
Bionic has had `__strlen_chk` for a while. Optimizing that into a constant is quite profitable, when possible. Differential Revision: https://reviews.llvm.org/D74079
2020-01-07[NFC] Use isX86() instead of getArch()Jim Lin1-4/+2
Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
2019-12-16[TLI] Support for per-Function TLI that overrides available libfuncsTeresa Johnson1-18/+8
Summary: Follow-on to D66428 and D71193, to build the TLI per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. With D71193, the -fno-builtin* flags are converted to function attributes, so we can now set this information per-function on the TLI. In this patch, the TLI constructor is changed to take a Function, which can be used to override the available builtins. The TLI is augmented with an array that can be used to specify which builtins are not available for the corresponding function. The available function checks are changed to consult this override before checking the underlying module level baseline TLII. New code is added to set this override array based on the attributes. I also removed the code that sets availability in the TLII in clang from the options, which is no longer needed. I removed a per-Triple caching of TLII objects in the analysis object, as it is based on the Module's Triple which is the same for all functions in any case. Is there a case where we would be compiling multiple Modules with different Triples in one compilation? Finally, I have changed the legacy analysis wrapper to create and use the new PM analysis class (TargetLibraryAnalysis) in getTLI. This is consistent with the behavior of getTTI for the legacy TargetTransformInfo analysis. This change means that getTLI now creates a new TLI on each call (although that should be very cheap as we cache the module level TLII, and computing the per-function attribute based availability should also be reasonably efficient). I measured the compile time for a large C++ file with tens of thousands of functions and as expected there was no increase. Reviewers: chandlerc, hfinkel, gchatelet Subscribers: mehdi_amini, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67923
2019-11-15[SVFS] Inject TLI Mappings in VFABI attribute.Francesco Petrogalli1-0/+16
This patch introduces a function pass to inject the scalar-to-vector mappings stored in the TargetLIbraryInfo (TLI) into the Vector Function ABI (VFABI) variants attribute. The test is testing the injection for three vector libraries supported by the TLI (Accelerate, SVML, MASSV). The pass does not change any of the analysis associated to the function. Differential Revision: https://reviews.llvm.org/D70107
2019-11-13Sink all InitializePasses.h includesReid Kleckner1-0/+1
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
2019-09-11[TLI][AMDGPU] AMDPAL does not have library functionsTim Renouf1-12/+2
Configure TLI to say that r600/amdgpu does not have any library functions, such that InstCombine does not do anything like turn sin/cos into the library function @tan with sufficient fast math flags. Differential Revision: https://reviews.llvm.org/D67406 Change-Id: I02f907d3e64832117ea9800e9f9285282856e5df llvm-svn: 371592
2019-09-07Change TargetLibraryInfo analysis passes to always require FunctionTeresa Johnson1-8/+0
Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
2019-09-04[TargetLibraryInfo] Define enumerator for no library function (NFC)Evandro Menezes1-0/+1
Add a null enumerator do designate no library function. llvm-svn: 370947
2019-08-24[TLI] Simplify code. NFCI.Benjamin Kramer1-9/+4
llvm-svn: 369854
2019-08-24Fix some accidental global initializers by using StringLiteral instead of ↵Benjamin Kramer1-2/+3
StringRef llvm-svn: 369850
2019-08-12[AMDGPU] Printf runtime binding passStanislav Mekhanoshin1-0/+1
This pass is a port of the according pass from the HSAIL compiler. It parses printf calls and setup runtime printf buffer. After that it copies printf arguments to the buffer and fills in module metadata for runtime. Differential Revision: https://reviews.llvm.org/D24035 llvm-svn: 368592
2019-08-07TLI: darwin does not support _bcmpAlex Lorenz1-1/+1
Not all Darwin targets support _bcmp in all circumstances. Differential Revision: https://reviews.llvm.org/D65834 llvm-svn: 368113
2019-08-05[TLI][NFC] Fixed typoDavid Bolvansky1-1/+1
llvm-svn: 367827
2019-06-05Initial support for IBM MASS vector libraryNemanja Ivanovic1-0/+10
This is the LLVM portion of patch https://reviews.llvm.org/D59881. The clang portion is to follow. llvm-svn: 362568
2019-05-31[SimplifyLibCalls] Fold more fortified functions into non-fortified variantsErik Pilkington1-0/+53
When the object size argument is -1, no checking can be done, so calling the _chk variant is unnecessary. We already did this for a bunch of these functions. rdar://50797197 Differential revision: https://reviews.llvm.org/D62358 llvm-svn: 362272
2019-05-16Add Triple::isPPC64()Fangrui Song1-2/+2
llvm-svn: 360864
2019-05-09Compile time tweak for libcall lookupPhilip Reames1-0/+5
If we have a large module which is mostly intrinsics, we hammer the lib call lookup path from CodeGenPrepare. Adding a fastpath reduces compile by 15% for one such example. The problem is really more general than intrinsics - a module with lots of non-intrinsics non-libcall calls has the same problem - but we might as well avoid an easy case quickly. llvm-svn: 360391
2019-04-12Use llvm::lower_bound. NFCFangrui Song1-7/+6
This reapplies rL358161. That commit inadvertently reverted an exegesis file to an old version. llvm-svn: 358246
2019-04-11Revert "Use llvm::lower_bound. NFC"Ali Tamur1-6/+7
This reverts commit rL358161. This patch have broken the test: llvm/test/tools/llvm-exegesis/X86/uops-CMOV16rm-noreg.s llvm-svn: 358199
2019-04-11Use llvm::lower_bound. NFCFangrui Song1-7/+6
llvm-svn: 358161
2019-04-09NFC: Refactor library-specific mappings of scalar maths functions to their ↵Nemanja Ivanovic1-139/+4
vector counterparts This patch factors out mappings of scalar maths functions to their vector counterparts from TargetLibraryInfo.cpp to a separate VecFuncs.def file. Such mappings are currently available for Accelerate framework, and SVML library. This is in support of the follow-up: https://reviews.llvm.org/D59881 Patch by pjeeva01 Differential revision: https://reviews.llvm.org/D60211 llvm-svn: 358001
2019-04-03[WebAssembly] Add Emscripten OS definition + small_printfAlon Zakai1-2/+13
The Emscripten OS provides a definition of __EMSCRIPTEN__, and also that it supports iprintf optimizations. Also define small_printf optimizations, which is a printf with float support but not long double (which in wasm can be useful since long doubles are 128 bit and force linking of float128 emulation code). This part is based on sunfish's https://reviews.llvm.org/D57620 (which can't land yet since the WASI integration isn't ready yet). Differential Revision: https://reviews.llvm.org/D60167 llvm-svn: 357552
2019-03-08[SelectionDAG] Allow the user to specify a memeq function.Clement Courbet1-0/+13
Summary: Right now, when we encounter a string equality check, e.g. `if (memcmp(a, b, s) == 0)`, we try to expand to a comparison if `s` is a small compile-time constant, and fall back on calling `memcmp()` else. This is sub-optimal because memcmp has to compute much more than equality. This patch replaces `memcmp(a, b, s) == 0` by `bcmp(a, b, s) == 0` on platforms that support `bcmp`. `bcmp` can be made much more efficient than `memcmp` because equality compare is trivially parallel while lexicographic ordering has a chain dependency. Subscribers: fedor.sergeev, jyknight, ckennelly, gchatelet, llvm-commits Differential Revision: https://reviews.llvm.org/D56593 llvm-svn: 355672
2019-02-11[TargetLibraryInfo] Update run time support for WindowsEvandro Menezes1-47/+39
It seems that, since VC19, the `float` C99 math functions are supported for all targets, unlike the C89 ones. According to the discussion at https://reviews.llvm.org/D57625. llvm-svn: 353758
2019-02-11[TargetLibraryInfo] Update run time support for WindowsEvandro Menezes1-35/+64
It seems that the run time for Windows has changed and supports more math functions than it used to, especially on AArch64, ARM, and AMD64. Fixes PR40541. Differential revision: https://reviews.llvm.org/D57625 llvm-svn: 353733
2019-02-05[TargetLibraryInfo] Regroup run time functions for Windows (NFC)Evandro Menezes1-38/+37
Regroup supported and unsupported functions by precision and C standard. llvm-svn: 353213
2019-02-04Revert "[PATCH] [TargetLibraryInfo] Update run time support for Windows"Evandro Menezes1-59/+53
This reverts accidental commit ff5527718d5d3b9966f6e8948866c0dc15ffcf3c. llvm-svn: 353118
2019-02-04[PATCH] [TargetLibraryInfo] Update run time support for WindowsEvandro Menezes1-53/+59
It seems that the run time for Windows has changed and supports more math functions than before. Since LLVM requires at least VS2015, I assume that this is the run time that would be redistributed with programs built with Clang. Thus, I based this update on the header file `math.h` that accompanies it. This patch addresses the PR40541. Unfortunately, I have no access to a Windows development environment to validate it. llvm-svn: 353114
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-11-24Revert unapproved commitJoel Jones1-154/+4
llvm-svn: 347511
2018-11-24[AArch64] Enable libm vectorized functions via SLEEFJoel Jones1-4/+154
This changeset is modeled after Intel's submission for SVML. It enables trigonometry functions vectorization via SLEEF: http://sleef.org/. * A new vectorization library enum is added to TargetLibraryInfo.h: SLEEF. * A new option is added to TargetLibraryInfoImpl - ClVectorLibrary: SLEEF. * A comprehensive test case is included in this changeset. * In a separate changeset (for clang), a new vectorization library argument is added to -fveclib: -fveclib=SLEEF. Trigonometry functions that are vectorized by sleef: acos asin atan atanh cos cosh exp exp2 exp10 lgamma log10 log2 log sin sinh sqrt tan tanh tgamma Patch by Stefan Teleman Differential Revision: https://reviews.llvm.org/D53927 llvm-svn: 347510
2018-11-07Fix unit tests after patch https://reviews.llvm.org/rL346313Calixte Denizet1-5/+1
Summary: Tests are broken so fix them. Reviewers: marco-c Reviewed By: marco-c Subscribers: sylvestre.ledru, llvm-commits Differential Revision: https://reviews.llvm.org/D54208 llvm-svn: 346318
2018-11-07[GCOV] Flush counters before to avoid counting the execution before fork ↵Calixte Denizet1-0/+24
twice and for exec** functions we must flush before the call Summary: This is replacement for patch in https://reviews.llvm.org/D49460. When we fork, the counters are duplicate as they're and so the values are finally wrong when writing gcda for parent and child. So just before to fork, we flush the counters and so the parent and the child have new counters set to zero. For exec** functions, we need to flush before the call to have some data. Reviewers: vsk, davidxl, marco-c Reviewed By: marco-c Subscribers: llvm-commits, sylvestre.ledru, marco-c Differential Revision: https://reviews.llvm.org/D53593 llvm-svn: 346313
2018-11-06Disable calls to *_finite and other glibc-only functions on Musl.Eli Friedman1-5/+5
Non-GNU environments don't have __finite_*, so treat them as unavailable. Differential Revision: https://reviews.llvm.org/D51282 llvm-svn: 346250
2018-09-27llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song1-2/+2
Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
2018-06-25Add Triple::isMIPS()/isMIPS32()/isMIPS64(). NFCAlexander Richardson1-2/+1
There are quite a few if statements that enumerate all these cases. It gets even worse in our fork of LLVM where we also have a Triple::cheri (which is mips64 + CHERI instructions) and we had to update all if statements that check for Triple::mips64 to also handle Triple::cheri. This patch helps to reduce our diff to upstream and should also make some checks more readable. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D48548 llvm-svn: 335493
2018-06-07[TargetLibraryInfo] add mappings from LLVM sin/cos intrinsics to SVML callsSanjay Patel1-0/+16
These weren't included in D19544 - probably just an oversight. D40044 made it more likely that we'll have LLVM math intrinsics rather than libcalls, so this bug was more easily exposed. As the tests/code show, we already have the complete mappings for pow/exp/log. I don't have any experience with SVML, so I don't know if anything else is missing. It's also not clear to me that we should be doing this transform in IR rather than DAG/isel, but that's a separate issue. Differential Revision: https://reviews.llvm.org/D47610 llvm-svn: 334211
2018-05-17[Analysis] Only use _unlocked stdio functions on linuxMartin Storsjo1-1/+2
The existing comment said that the functions were available only on GNU/Linux (and on certain Android versions), but only checked T.isGNUEnvironment() which also is true on MinGW (for arch-windows-gnu triplets), which doesn't have such functions. Existing checks in the initialize function in TargetLibraryInfo.cpp also use only T.isOSLinux() to check for glibc features. This fixes use of stdio on MinGW. Differential Revision: https://reviews.llvm.org/D47002 llvm-svn: 332581
2018-05-16[SimplifyLibcalls] Replace locked IO with unlocked IODavid Bolvansky1-1/+41
Summary: If file stream arg is not captured and source is fopen, we could replace IO calls by unlocked IO ("_unlocked" function variants) to gain better speed, Reviewers: efriedma, RKSimon, spatel, sanjoy, hfinkel, majnemer, lebedev.ri, rja Reviewed By: rja Subscribers: rja, srhines, efriedma, lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D45736 llvm-svn: 332452