aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/TargetLibraryInfo.cpp
AgeCommit message (Collapse)AuthorFilesLines
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
2018-05-11[Analysis] Validate the return type of s(n)printf like libcallsMartin Storsjo1-2/+4
If the sprintf function is static (as on mingw-w64, where many stdio functions are static inline wrappers), earlier optimization passes could optimize out the return value altogether, and make it void, which could break optimizations of this libcall that touch the return value. This fixes the issue discussed in PR37408 for the sprintf function. Differential Revision: https://reviews.llvm.org/D46752 llvm-svn: 332106
2018-04-27Revert "[SimplifyLibcalls] Replace locked IO with unlocked IO"Matt Morehouse1-41/+1
This reverts r331002 due to sanitizer bot breakage. llvm-svn: 331011
2018-04-26[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 Subscribers: lebedev.ri, llvm-commits Differential Revision: https://reviews.llvm.org/D45736 llvm-svn: 331002
2018-04-04[Analysis] Support aligned new/delete functions.Eric Fiselier1-0/+28
Summary: Clang's __builtin_operator_new/delete was recently taught about the aligned allocation overloads (r328134). This patch makes LLVM aware of them as well. This allows the compiler to perform certain optimizations including eliding new/delete calls. Reviewers: rsmith, majnemer, dblaikie, vsk, bkramer Reviewed By: bkramer Subscribers: ckennelly, llvm-commits Differential Revision: https://reviews.llvm.org/D44769 llvm-svn: 329218
2018-04-04Revert "[Analysis] Support aligned new/delete functions."Eric Fiselier1-28/+0
This reverts commit bee3bbd9bdd3ab3364b8fb0cdb6326bc1ae740e0. llvm-svn: 329217
2018-04-04[Analysis] Support aligned new/delete functions.Eric Fiselier1-0/+28
Summary: Clang's __builtin_operator_new/delete was recently taught about the aligned allocation overloads (r328134). This patch makes LLVM aware of them as well. This allows the compiler to perform certain optimizations including eliding new/delete calls. Reviewers: rsmith, majnemer, dblaikie, vsk, bkramer Reviewed By: bkramer Subscribers: ckennelly, llvm-commits Differential Revision: https://reviews.llvm.org/D44769 llvm-svn: 329215
2018-04-01[Analysis] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang1-2/+2
Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer D44363 for a list of all the required patches. Reviewers: sanjoy, dexonsmith, hfinkel, RKSimon Reviewed By: dexonsmith Subscribers: david2050, llvm-commits Differential Revision: https://reviews.llvm.org/D44944 llvm-svn: 328925
2018-03-30Fix a bunch of typoes. NFCFangrui Song1-1/+1
llvm-svn: 328907
2018-01-31[Analysis] Disable calls to *_finite and other glibc-only functions on Android.Chih-Hung Hsieh1-12/+6
Since r322087, glibc's finite lib calls are generated when possible. However, they are not supported on Android. This change also disables other functions not available on Android. Differential Revision: http://reviews.llvm.org/D42668 llvm-svn: 323898
2018-01-23[Analysis] Disable exp/exp2/pow finite lib calls on Android with -ffast-math.MinSeong Kim1-0/+9
Summary: Since r322087, glibc's finite lib calls are generated when possible. However, glibc is not supported on Android. Therefore this change enables llvm to finely distinguish between linux and Android for unsupported library calls. The change also include some regression tests. Reviewers: srhines, pirama Reviewed By: srhines Subscribers: kongyi, chh, javed.absar, llvm-commits Differential Revision: https://reviews.llvm.org/D42288 llvm-svn: 323187
2018-01-08[TargetLibraryInfo] fix finite mathlib function availabilitySanjay Patel1-44/+44
This patch was part of: https://reviews.llvm.org/D41338 ...but we can expose the bug in IR via constant propagation as shown in the test. Unless the triple includes 'linux', we should not fold these because the functions don't exist on other platforms (yet?). llvm-svn: 322010
2017-12-18[TargetLibraryInfo] Discard library functions with incorrectly sized integersIgor Laevsky1-3/+3
Differential Revision: https://reviews.llvm.org/D41184 llvm-svn: 320964
2017-12-16[SimplifyLibCalls] Inline calls to cabs when it's safe to do soHal Finkel1-0/+22
When unsafe algerbra is allowed calls to cabs(r) can be replaced by: sqrt(creal(r)*creal(r) + cimag(r)*cimag(r)) Patch by Paul Walker, thanks! Differential Revision: https://reviews.llvm.org/D40069 llvm-svn: 320901
2017-12-15[TargetLibraryInfo] fix documentation comment; NFCSanjay Patel1-3/+3
llvm-svn: 320842
2017-09-26TargetLibraryInfo: Stop guessing wchar_t sizeMatthias Braun1-10/+1
Usually the frontend communicates the size of wchar_t via metadata and we can optimize wcslen (and possibly other calls in the future). In cases without the wchar_size metadata we would previously try to guess the correct size based on the target triple; however this is fragile to keep up to date and may miss users manually changing the size via flags. Better be safe and stop guessing and optimizing if the frontend didn't communicate the size. Differential Revision: https://reviews.llvm.org/D38106 llvm-svn: 314185
2017-05-21Revert "Add pthread_self function prototype and make it speculatable."Xin Tong1-9/+0
This reverts commit 143d7445b5dfa2f6d6c45bdbe0433d9fc531be21. Build breaking llvm-svn: 303496
2017-05-20Add pthread_self function prototype and make it speculatable.Xin Tong1-0/+9
Summary: This allows pthread_self to be pulled out of a loop by LICM. Reviewers: hfinkel, arsenm, davide Reviewed By: davide Subscribers: davide, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D32782 llvm-svn: 303495
2017-05-20Fix breakage after r303461Matthias Braun1-1/+5
- Improve wchar_t size predicitions based on target triple. - Be less strict in wchar_t size verifier. llvm-svn: 303477
2017-05-19SimplifyLibCalls: Optimize wcslenMatthias Braun1-0/+12
Refactor the strlen optimization code to work for both strlen and wcslen. This especially helps with programs in the wild where people pass L"string"s to const std::wstring& function parameters and the wstring constructor gets inlined. This also fixes a lingerind API problem/bug in getConstantStringInfo() where zeroinitializers would always give you an empty string (without a length) back regardless of the actual length of the initializer which did not work well in the TrimAtNul==false causing the PR mentioned below. Note that the fixed getConstantStringInfo() needed fixes to SelectionDAG memcpy lowering and may lead to some cases for out-of-bounds zeroinitializer accesses not getting optimized anymore. So some code with UB may produce out of bound memory reads now instead of just producing zeros. The refactoring "accidentally" fixes http://llvm.org/PR32124 Differential Revision: https://reviews.llvm.org/D32839 llvm-svn: 303461
generated by cgit v1.1 at 2025-10-09 02:10:12 +0000