summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Convert OptimizationRemarkEmitter old emit() calls to new closureVivek Pandya2017-10-111-2/+4
| | | | | | | | | | | | | | parameterized emit() calls Summary: This is not functional change to adopt new emit() API added in r313691. Reviewed By: anemet Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D38285 llvm-svn: 315476
* Rename OptimizationDiagnosticInfo.* to OptimizationRemarkEmitter.*Adam Nemet2017-10-091-1/+1
| | | | | | | Sync it up with the name of the class actually defined here. This has been bothering me for a while... llvm-svn: 315249
* TargetLibraryInfo: Stop guessing wchar_t sizeMatthias Braun2017-09-261-0/+3
| | | | | | | | | | | | | | 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
* [LibCallSimplifier] try harder to fold memcmp with constant arguments (2nd try)Sanjay Patel2017-08-211-14/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | The 1st try was reverted because it could inf-loop by creating a dead instruction. Fixed that to not happen and added a test case to verify. Original commit message: Try to fold: memcmp(X, C, ConstantLength) == 0 --> load X == *C Without this change, we're unnecessarily checking the alignment of the constant data, so we miss the transform in the first 2 tests in the patch. I noted this shortcoming of LibCallSimpifier in one of the recent CGP memcmp expansion patches. This doesn't help the example in: https://bugs.llvm.org/show_bug.cgi?id=34032#c13 ...directly, but it's worth short-circuiting more of these simple cases since we're already trying to do that. The benefit of transforming to load+cmp is that existing IR analysis/transforms may further simplify that code. For example, if the load of the variable is common to multiple memcmp calls, CSE can remove the duplicate instructions. Differential Revision: https://reviews.llvm.org/D36922 llvm-svn: 311366
* revert r311333: [LibCallSimplifier] try harder to fold memcmp with constant ↵Sanjay Patel2017-08-211-26/+10
| | | | | | | | | | arguments We're getting lots of compile-timeout bot failures like: http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/7119 http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux llvm-svn: 311340
* [LibCallSimplifier] try harder to fold memcmp with constant argumentsSanjay Patel2017-08-211-10/+26
| | | | | | | | | | | | | | | | | | | | | | Try to fold: memcmp(X, C, ConstantLength) == 0 --> load X == *C Without this change, we're unnecessarily checking the alignment of the constant data, so we miss the transform in the first 2 tests in the patch. I noted this shortcoming of LibCallSimpifier in one of the recent CGP memcmp expansion patches. This doesn't help the example in: https://bugs.llvm.org/show_bug.cgi?id=34032#c13 ...directly, but it's worth short-circuiting more of these simple cases since we're already trying to do that. The benefit of transforming to load+cmp is that existing IR analysis/transforms may further simplify that code. For example, if the load of the variable is common to multiple memcmp calls, CSE can remove the duplicate instructions. Differential Revision: https://reviews.llvm.org/D36922 llvm-svn: 311333
* Add strictfp attribute to prevent unwanted optimizations of libm callsAndrew Kaylor2017-08-141-76/+97
| | | | | | Differential Revision: https://reviews.llvm.org/D34163 llvm-svn: 310885
* Migrate SimplifyLibCalls to new OptimizationRemarkEmitterAdam Nemet2017-07-261-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This changes SimplifyLibCalls to use the new OptimizationRemarkEmitter API. In fact, as SimplifyLibCalls is only ever called via InstCombine, (as far as I can tell) the OptimizationRemarkEmitter is added there, and then passed through to SimplifyLibCalls later. I have avoided changing any remark text. This closes PR33787 Patch by Sam Elliott! Reviewers: anemet, davide Reviewed By: anemet Subscribers: davide, mehdi_amini, eraman, fhahn, llvm-commits Differential Revision: https://reviews.llvm.org/D35608 llvm-svn: 309158
* [Constants] If we already have a ConstantInt*, prefer to use ↵Craig Topper2017-07-061-2/+2
| | | | | | | | isZero/isOne/isMinusOne instead of isNullValue/isOneValue/isAllOnesValue inherited from Constant. NFCI Going through the Constant methods requires redetermining that the Constant is a ConstantInt and then calling isZero/isOne/isMinusOne. llvm-svn: 307292
* [SimplifyLibCalls] fix formatting; NFCSanjay Patel2017-06-091-1/+1
| | | | llvm-svn: 305081
* [PPC] Inline expansion of memcmpZaara Syeda2017-05-311-14/+0
| | | | | | | | | | | | | | | This patch does an inline expansion of memcmp. It changes the memcmp library call into an inline expansion when the size is known at compile time and is under a target specified threshold. This expansion is implemented in CodeGenPrepare and expands into straight line code. The target specifies a maximum load size and the expansion works by using this size to load the two sources, compare, and exit early if a difference is found. It also has a special case when the memcmp result is used in a compare to zero equality. Differential Revision: https://reviews.llvm.org/D28637 llvm-svn: 304313
* [ValueTracking] Convert most of the calls to computeKnownBits to use the ↵Craig Topper2017-05-241-3/+1
| | | | | | | | | | version that returns the KnownBits object. This continues the changes started when computeSignBit was replaced with this new version of computeKnowBits. Differential Revision: https://reviews.llvm.org/D33431 llvm-svn: 303773
* SimplifyLibCalls: Optimize wcslenMatthias Braun2017-05-191-28/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Suppress all uses of LLVM_END_WITH_NULL. NFC.Serge Guelton2017-05-091-3/+3
| | | | | | | | | Use variadic templates instead of relying on <cstdarg> + sentinel. This enforces better type checking and makes code more readable. Differential Revision: https://reviews.llvm.org/D32541 llvm-svn: 302571
* [IR] Abstract away ArgNo+1 attribute indexing as much as possibleReid Kleckner2017-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Do three things to help with that: - Add AttributeList::FirstArgIndex, which is an enumerator currently set to 1. It allows us to change the indexing scheme with fewer changes. - Add addParamAttr/removeParamAttr. This just shortens addAttribute call sites that would otherwise need to spell out FirstArgIndex. - Remove some attribute-specific getters and setters from Function that take attribute list indices. Most of these were only used from BuildLibCalls, and doesNotAlias was only used to test or set if the return value is malloc-like. I'm happy to split the patch, but I think they are probably easier to review when taken together. This patch should be NFC, but it sets the stage to change the indexing scheme to this, which is more convenient when indexing into an array: 0: func attrs 1: retattrs 2...: arg attrs Reviewers: chandlerc, pete, javed.absar Subscribers: david2050, llvm-commits Differential Revision: https://reviews.llvm.org/D32811 llvm-svn: 302060
* [ValueTracking] Introduce a KnownBits struct to wrap the two APInts for ↵Craig Topper2017-04-261-6/+5
| | | | | | | | | | | | | | | | computeKnownBits This patch introduces a new KnownBits struct that wraps the two APInt used by computeKnownBits. This allows us to treat them as more of a unit. Initially I've just altered the signatures of computeKnownBits and InstCombine's simplifyDemandedBits to pass a KnownBits reference instead of two separate APInt references. I'll do similar to the SelectionDAG version of computeKnownBits/simplifyDemandedBits as a separate patch. I've added a constructor that allows initializing both APInts to the same bit width with a starting value of 0. This reduces the repeated pattern of initializing both APInts. Once place default constructed the APInts so I added a default constructor for those cases. Going forward I would like to add more methods that will work on the pairs. For example trunc, zext, and sext occur on both APInts together in several places. We should probably add a clear method that can be used to clear both pieces. Maybe a method to check for conflicting information. A method to return (Zero|One) so we don't write it out everywhere. Maybe a method for (Zero|One).isAllOnesValue() to determine if all bits are known. I'm sure there are many other methods we can come up with. Differential Revision: https://reviews.llvm.org/D32376 llvm-svn: 301432
* SimplifyLibCalls: Fix crash on memset(notmalloc())Matthias Braun2017-04-251-0/+3
| | | | | | rdar://31520787 llvm-svn: 301352
* [SimplifyLibCalls] Fix infinite loop with fast-math optimization.Andrew Ng2017-04-251-0/+18
| | | | | | | | | | | | | | | | | | One of the fast-math optimizations is to replace calls to standard double functions with their float equivalents, e.g. exp -> expf. However, this can cause infinite loops for the following: float expf(float val) { return (float) exp((double) val); } A similar inline declaration exists in the MinGW-w64 math.h header file which when compiled with -O2/3 and fast-math generates infinite loops. So this fix checks that the calling function to the standard double function that is being replaced does not match the float equivalent. Differential Revision: https://reviews.llvm.org/D31806 llvm-svn: 301304
* [SimplifyLibCalls] Remove a cl::opt that's been `true` for a long time.Davide Italiano2017-04-251-5/+1
| | | | llvm-svn: 301288
* Module::getOrInsertFunction is using C-style vararg instead of variadic ↵Serge Guelton2017-04-111-3/+3
| | | | | | | | | | | templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299949
* Revert "Turn some C-style vararg into variadic templates"Diana Picus2017-04-111-3/+3
| | | | | | | This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008 llvm-svn: 299928
* Turn some C-style vararg into variadic templatesSerge Guelton2017-04-111-3/+3
| | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. llvm-svn: 299925
* Revert "Turn some C-style vararg into variadic templates"Mehdi Amini2017-04-061-5/+6
| | | | | | This reverts commit r299699, the examples needs to be updated. llvm-svn: 299702
* Turn some C-style vararg into variadic templatesMehdi Amini2017-04-061-6/+5
| | | | | | | | | | | | | | | | Module::getOrInsertFunction is using C-style vararg instead of variadic templates. From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues. Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu> Differential Revision: https://reviews.llvm.org/D31070 llvm-svn: 299699
* Do not translate rint into nearbyint, but truncate it like nearbyint.Joerg Sonnenberger2017-03-311-1/+2
| | | | | | | | | | | | | | A common way to implement nearbyint is by fiddling with the floating point environment and calling rint. This is used at least by the BSD libm and musl. As such, canonicalizing the latter to the former will create infinite loops for libm and generally pessimize performance, at least when the generic C versions are used. This change preserves the rint in the libcall translation and also handles the domain truncation logic, so that rint with float argument will be reduced to rintf etc. llvm-svn: 299247
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* [LangRef] Make @llvm.sqrt(x) return undef, rather than have UB, for negative x.Justin Lebar2017-01-271-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Some frontends emit a speculate-and-select idiom for sqrt, wherein they compute sqrt(x), check if x is negative, and select NaN if it is: %cmp = fcmp olt double %a, -0.000000e+00 %sqrt = call double @llvm.sqrt.f64(double %a) %ret = select i1 %cmp, double 0x7FF8000000000000, double %sqrt This is technically UB as the LangRef is written today if %a is ever less than -0. But emitting code that's compliant with the current definition of sqrt would require a branch, which would then prevent us from matching this idiom in SelectionDAG (which we do today -- ISD::FSQRT has defined behavior on negative inputs), because SelectionDAG looks at one BB at a time. Nothing in LLVM takes advantage of this undefined behavior, as far as we can tell, and the fact that llvm.sqrt has UB dates from its initial addition to the LangRef. Reviewers: arsenm, mehdi_amini, hfinkel Subscribers: wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D28797 llvm-svn: 293242
* SimplifyLibCalls: Replace more unary libcalls with intrinsicsMatt Arsenault2017-01-231-28/+21
| | | | llvm-svn: 292855
* [Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones2017-01-231-158/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SimplifyLibCalls: Remove checks for fabsMatt Arsenault2017-01-171-5/+7
| | | | | | | Use the intrinsic instead of emitting the libcall which will be replaced by the intrinsic. llvm-svn: 292176
* SimplifyLibCalls: Replace fabs libcalls with intrinsicsMatt Arsenault2017-01-171-6/+8
| | | | | | | | Add missing fabs(fpext) optimzation that worked with the call, and also fixes it creating a second fpext when there were multiple uses. llvm-svn: 292172
* [SimplifyLibCalls] Propagate fast math flags while optimizing pow().Davide Italiano2017-01-101-1/+4
| | | | llvm-svn: 291577
* [SimplifyLibCalls] pow(x, -0.5) -> 1.0 / sqrt(x).Davide Italiano2017-01-091-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D28479 llvm-svn: 291486
* SimplifyLibCalls: Remove incorrect optimization of fabsMatt Arsenault2017-01-071-10/+2
| | | | | | | | fabs(x * x) is not generally safe to assume x is positive if x is a NaN. This is also less general than it could be, so this will be replaced with a transformation on the intrinsic. llvm-svn: 291359
* Revert @llvm.assume with operator bundles (r289755-r289757)Daniel Jasper2016-12-191-1/+2
| | | | | | | This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
* [SimplifyLibCalls] Use a lambda. NFCI.Davide Italiano2016-12-161-6/+6
| | | | llvm-svn: 289911
* [SimplifyLibCalls] Lower fls() to llvm.ctlz().Davide Italiano2016-12-151-0/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D14590 llvm-svn: 289894
* [SimplifyLibCalls] Remove redundant folding logic for ffs().Davide Italiano2016-12-151-13/+3
| | | | | | | | Lowering to llvm.cttz() will result in constant folding anyway if the argument to ffs is a constant. Pointed out by Eli for fls() in D14590. llvm-svn: 289888
* Remove the AssumptionCacheHal Finkel2016-12-151-2/+1
| | | | | | | | | After r289755, the AssumptionCache is no longer needed. Variables affected by assumptions are now found by using the new operand-bundle-based scheme. This new scheme is more computationally efficient, and also we need much less code... llvm-svn: 289756
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-2/+2
| | | | | | | | | | | | | At least the plugin used by the LibreOffice build (<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly uses those members (through inline functions in LLVM/Clang include files in turn using them), but they are not exported by utils/extract_symbols.py on Windows, and accessing data across DLL/EXE boundaries on Windows is generally problematic. Differential Revision: https://reviews.llvm.org/D26671 llvm-svn: 289647
* Enable simplify libcalls for ARM PCSSam Parker2016-09-131-3/+35
| | | | | | | | | | Teach SimplifyLibcalls that in can treat functions annotated with apcs, aapcs or aapcs_vfp like normal C functions if they only take and return integer or pointer values, and the target is not iOS. Differential Revision: https://reviews.llvm.org/D24453 llvm-svn: 281322
* Use range algorithms instead of unpacking begin/endDavid Majnemer2016-08-111-1/+1
| | | | | | No functionality change is intended. llvm-svn: 278417
* [SimplifyLibCalls] Restore the old behaviour, emit a libcall.Davide Italiano2016-08-101-3/+5
| | | | | | | | Hal pointed out that the semantic of our intrinsic and the libc call are slightly different. Add a comment while I'm here to explain why we can't emit an intrinsic. Thanks Hal! llvm-svn: 278200
* [SimplifyLibCalls] Emit sqrt intrinsic instead of a libcall.Davide Italiano2016-08-081-2/+3
| | | | llvm-svn: 277972
* [SLC] Emit an intrinsic instead of a libcall for pow.Davide Italiano2016-08-071-9/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D22104 llvm-svn: 277963
* Addressing post-commit comments for not rewriting fputs:Sjoerd Meijer2016-07-071-2/+5
| | | | | | moved the optimise for size check inside function optimizeFPuts. llvm-svn: 274758
* Code size optimisation: don't rewrite fputs to fwrite when optimising for sizeSjoerd Meijer2016-07-071-0/+2
| | | | | | because fwrite requires more arguments and thus extra MOVs are required. llvm-svn: 274753
* Optimize a printf with a double procent to putchar.Joerg Sonnenberger2016-05-091-2/+2
| | | | llvm-svn: 268922
* [TLI] Unify LibFunc signature checking. NFCI.Ahmed Bougacha2016-04-271-362/+17
| | | | | | | | | I tried to be as close as possible to the strongest check that existed before; cleaning these up properly is left for future work. Differential Revision: http://reviews.llvm.org/D19469 llvm-svn: 267758
* Revert "[SimplifyLibCalls] sprintf doesn't copy null bytes"David Majnemer2016-04-261-4/+3
| | | | | | | | | | The destination buffer that sprintf uses is restrict qualified, we do not need to worry about derived pointers referenced via format specifiers. This reverts commit r267580. llvm-svn: 267605
OpenPOWER on IntegriCloud