summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/TargetLibraryInfo.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add Triple::isMIPS()/isMIPS32()/isMIPS64(). NFCAlexander Richardson2018-06-251-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
* [TargetLibraryInfo] add mappings from LLVM sin/cos intrinsics to SVML callsSanjay Patel2018-06-071-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
* [Analysis] Only use _unlocked stdio functions on linuxMartin Storsjo2018-05-171-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
* [SimplifyLibcalls] Replace locked IO with unlocked IODavid Bolvansky2018-05-161-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
* [Analysis] Validate the return type of s(n)printf like libcallsMartin Storsjo2018-05-111-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
* Revert "[SimplifyLibcalls] Replace locked IO with unlocked IO"Matt Morehouse2018-04-271-41/+1
| | | | | | This reverts r331002 due to sanitizer bot breakage. llvm-svn: 331011
* [SimplifyLibcalls] Replace locked IO with unlocked IODavid Bolvansky2018-04-261-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
* [Analysis] Support aligned new/delete functions.Eric Fiselier2018-04-041-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
* Revert "[Analysis] Support aligned new/delete functions."Eric Fiselier2018-04-041-28/+0
| | | | | | This reverts commit bee3bbd9bdd3ab3364b8fb0cdb6326bc1ae740e0. llvm-svn: 329217
* [Analysis] Support aligned new/delete functions.Eric Fiselier2018-04-041-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
* [Analysis] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-011-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
* Fix a bunch of typoes. NFCFangrui Song2018-03-301-1/+1
| | | | llvm-svn: 328907
* [Analysis] Disable calls to *_finite and other glibc-only functions on Android.Chih-Hung Hsieh2018-01-311-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
* [Analysis] Disable exp/exp2/pow finite lib calls on Android with -ffast-math.MinSeong Kim2018-01-231-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
* [TargetLibraryInfo] fix finite mathlib function availabilitySanjay Patel2018-01-081-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
* [TargetLibraryInfo] Discard library functions with incorrectly sized integersIgor Laevsky2017-12-181-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D41184 llvm-svn: 320964
* [SimplifyLibCalls] Inline calls to cabs when it's safe to do soHal Finkel2017-12-161-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
* [TargetLibraryInfo] fix documentation comment; NFCSanjay Patel2017-12-151-3/+3
| | | | llvm-svn: 320842
* TargetLibraryInfo: Stop guessing wchar_t sizeMatthias Braun2017-09-261-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
* Revert "Add pthread_self function prototype and make it speculatable."Xin Tong2017-05-211-9/+0
| | | | | | | | This reverts commit 143d7445b5dfa2f6d6c45bdbe0433d9fc531be21. Build breaking llvm-svn: 303496
* Add pthread_self function prototype and make it speculatable.Xin Tong2017-05-201-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
* Fix breakage after r303461Matthias Braun2017-05-201-1/+5
| | | | | | | - Improve wchar_t size predicitions based on target triple. - Be less strict in wchar_t size verifier. llvm-svn: 303477
* SimplifyLibCalls: Optimize wcslenMatthias Braun2017-05-191-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
* IR: Give function GlobalValue::getRealLinkageName() a less misleading name: ↵Peter Collingbourne2017-05-161-1/+1
| | | | | | | | | | | | dropLLVMManglingEscape(). This function gives the wrong answer on some non-ELF platforms in some cases. The function that does the right thing lives in Mangler.h. To try to discourage people from using this function, give it a different name. Differential Revision: https://reviews.llvm.org/D33162 llvm-svn: 303134
* [TLI] Add mapping for various '__<func>_finite' forms of the math routines ↵Andrew Kaylor2017-05-121-0/+24
| | | | | | | | | | to SVML routines Patch by Chris Chrulski Differential Revision: https://reviews.llvm.org/D31789 llvm-svn: 302957
* [TLI] Add declarations for various math header file routines from ↵Andrew Kaylor2017-05-121-0/+86
| | | | | | | | | | math-finite.h that create '__<func>_finite as functions Patch by Chris Chrulski Differential Revision: https://reviews.llvm.org/D31787 llvm-svn: 302955
* TargetLibraryInfo: Introduce wcslenMatthias Braun2017-05-051-0/+4
| | | | | | | | | | | wcslen is part of the C99 and C++98 standards. - This introduces the function to TargetLibraryInfo. - Also set attributes for wcslen in llvm::inferLibFuncAttributes(). Differential Revision: https://reviews.llvm.org/D32837 llvm-svn: 302278
* [Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones2017-01-231-569/+569
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The LibFunc::Func enum holds enumerators named for libc functions. Unfortunately, there are real situations, including libc implementations, where function names are actually macros (musl uses "#define fopen64 fopen", for example; any other transitively visible macro would have similar effects). Strictly speaking, a conforming C++ Standard Library should provide any such macros as functions instead (via <cstdio>). However, there are some "library" functions which are not part of the standard, and thus not subject to this rule (fopen64, for example). So, in order to be both portable and consistent, the enum should not use the bare function names. The old enum naming used a namespace LibFunc and an enum Func, with bare enumerators. This patch changes LibFunc to be an enum with enumerators prefixed with "LibFFunc_". (Unfortunately, a scoped enum is not sufficient to override macros.) There are additional changes required in clang. Reviewers: rsmith Subscribers: mehdi_amini, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D28476 llvm-svn: 292848
* [TLI] Appease spurious MSVC warning using llvm_unreachable. NFC.Ahmed Bougacha2017-01-171-1/+2
| | | | | | | | | | | | | r292188 confused MSVC because of the combined lack of a default case and return statement. Move the unreachable outside of the NumLibFuncs case, to make it obvious that all cases should be handled. llvm_unreachable is __declspec(noreturn), so I'm assuming this does appease MSVC. llvm-svn: 292246
* [TLI] Add prototype checking for all remaining LibFuncs.Ahmed Bougacha2017-01-171-31/+186
| | | | | | | | | | | | | | This is another step towards unifying all LibFunc prototype checks. This work started in r267758 (D19469); add the remaining checks. Also add a unittest that checks each libfunc declared with a known-valid and known-invalid prototype. New libfuncs added in the future are required to have prototype checking in place; the known-valid test will fail otherwise. Differential Revision: https://reviews.llvm.org/D28030 llvm-svn: 292188
* [TLI] Alphabetize some of the prototype check switch. NFC.Ahmed Bougacha2017-01-171-27/+27
| | | | llvm-svn: 292187
* [SimplifyLibCalls] Lower fls() to llvm.ctlz().Davide Italiano2016-12-151-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D14590 llvm-svn: 289894
* [PM] Change the static object whose address is used to uniquely identifyChandler Carruth2016-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
* [TLI] Fix breakage introduced by D21739.Marcin Koscielnicki2016-11-211-19/+19
| | | | | | | | | The initialize function has an early return for AMDGPU targets. If taken, the ShouldExtI32* initialization code will not be executed, resulting in invalid values in the corresponding fields. Fix this by moving the code to the top of the function. llvm-svn: 287570
* [TLI] Add functions determining if int parameters/returns should be ↵Marcin Koscielnicki2016-11-211-2/+32
| | | | | | | | | | | | | | | zeroext/signext. On some architectures (s390x, ppc64, sparc64, mips), C-level int is passed as i32 signext instead of plain i32. Likewise, unsigned int may be passed as i32, i32 signext, or i32 zeroext depending on the platform. Add this information to TargetLibraryInfo, to be used whenever some LLVM pass inserts a compiler-rt call to a function involving int parameters or returns. Differential Revision: http://reviews.llvm.org/D21739 llvm-svn: 287533
* Turn cl::values() (for enum) from a vararg function to using C++ variadic ↵Mehdi Amini2016-10-081-2/+1
| | | | | | | | | | | | | | | template The core of the change is supposed to be NFC, however it also fixes what I believe was an undefined behavior when calling: va_start(ValueArgs, Desc); with Desc being a StringRef. Differential Revision: https://reviews.llvm.org/D25342 llvm-svn: 283671
* Use StringRef in TLI instead of raw pointer (NFC)Mehdi Amini2016-10-011-15/+13
| | | | llvm-svn: 283005
* [TLI] isdigit / isascii / toascii param type should match return type (PR30484)Sanjay Patel2016-09-231-1/+4
| | | | | | We crash in LibCallSimplifier if we don't check the validity of the function signature properly. llvm-svn: 282278
* [InferAttributes] Don't access parameters that don't exist.Michael Kuperstein2016-09-201-2/+2
| | | | | | | Check for the correct number of parameters before querying their type. This fixes PR30455. llvm-svn: 282038
* Replace a few more "fall through" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-0/+1
| | | | | | Follow up to r278902. I had missed "fall through", with a space. llvm-svn: 278970
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-4/+4
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* Recommitting r275284: add support to inline __builtin_mempcpyAndrew Kaylor2016-07-291-0/+1
| | | | | | | | Patch by Sunita Marathe Third try, now following fixes to MSan to handle mempcy in such a way that this commit won't break the MSan buildbots. (Thanks, Evegenii!) llvm-svn: 277189
* Initial support for vectorization using svml (short vector math library).Matt Masten2016-07-291-1/+71
| | | | | | Differential Revision: https://reviews.llvm.org/D19544 llvm-svn: 277166
* test commitMatt Masten2016-07-271-0/+1
| | | | llvm-svn: 276911
* Reverting r276771 due to MSan failures.Andrew Kaylor2016-07-271-1/+0
| | | | llvm-svn: 276824
* Re-committing r275284: add support to inline __builtin_mempcpyAndrew Kaylor2016-07-261-0/+1
| | | | | | | | Patch by Sunita Marathe Differential Revision: http://reviews.llvm.org/D21920 llvm-svn: 276771
* Reverting r275284 due to platform-specific test failuresAndrew Kaylor2016-07-131-1/+0
| | | | llvm-svn: 275304
* Fix for Bug 26903, adds support to inline __builtin_mempcpyAndrew Kaylor2016-07-131-0/+1
| | | | | | | | Patch by Sunita Marathe Differential Revision: http://reviews.llvm.org/D21920 llvm-svn: 275284
* [TargetLibraryInfo] Reduce code duplication.Davide Italiano2016-06-211-9/+1
| | | | llvm-svn: 273241
* [PM] Remove support for omitting the AnalysisManager argument to newChandler Carruth2016-06-171-2/+4
| | | | | | | | | | | | | | | | | | | | pass manager passes' `run` methods. This removes a bunch of SFINAE goop from the pass manager and just requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead argument. This is a small price to pay for the simplicity of the system as a whole, despite the noise that changing it causes at this stage. This will also helpfull allow us to make the signature of the run methods much more flexible for different kinds af passes to support things like intelligently updating the pass's progression over IR units. While this touches many, many, files, the changes are really boring. Mostly made with the help of my trusty perl one liners. Thanks to Sean and Hal for bouncing ideas for this with me in IRC. llvm-svn: 272978
OpenPOWER on IntegriCloud