summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/ConstantFolding.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Added missing break; added LLVM_FALLTHROUGH to address warning: this ↵Galina Kistanova2017-05-311-0/+2
| | | | | | statement may fall through. NFC. llvm-svn: 304340
* [ValueTracking] Convert most of the calls to computeKnownBits to use the ↵Craig Topper2017-05-241-5/+2
| | | | | | | | | | 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
* [ConstantFolding] Add folding for various math '__<func>_finite' routines ↵Andrew Kaylor2017-05-121-11/+69
| | | | | | | | | | generated from -ffast-math Patch by Chris Chrulski Differential Revision: https://reviews.llvm.org/D31788 llvm-svn: 302956
* [KnownBits] Add methods for determining if KnownBits is a constant valueCraig Topper2017-05-031-5/+4
| | | | | | | | This patch adds isConstant and getConstant for determining if KnownBits represents a constant value and to retrieve the value. Use them to simplify code. Differential Revision: https://reviews.llvm.org/D32785 llvm-svn: 302091
* [ValueTracking] Introduce a KnownBits struct to wrap the two APInts for ↵Craig Topper2017-04-261-8/+9
| | | | | | | | | | | | | | | | 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
* [ConstantFolding] Use Intrinsic::not_intrinsic instead of 0 for readability. ↵Craig Topper2017-04-071-1/+1
| | | | | | NFCI llvm-svn: 299801
* [ConstantFolding] Fix to prevent constant folding having to repeatedly scan ↵David Green2017-03-211-1/+1
| | | | | | | | | | | | | operands. NFCI After the loop unroll threshold was increased in r295538, very large constant expressions can be created. This prevents them from having to be recursively scanned, leading to a compile time blow-up. Differential Revision: https://reviews.llvm.org/D30689 llvm-svn: 298356
* Use MutableArrayRef for APFloat::convertToIntegerSimon Pilgrim2017-03-201-3/+3
| | | | | | As discussed on D31074, use MutableArrayRef for destination integer buffers to help assert before stack overflows happen. llvm-svn: 298253
* [Analysis] bitreverse(undef) returns undefBrian Gesiak2017-03-191-1/+2
| | | | | | | | | | | | | | | | Summary: The reverse of an artbitrary bitpattern is also an arbitrary bitpattern. Reviewers: trentxintong, arsenm, majnemer Reviewed By: majnemer Subscribers: majnemer, wdng, llvm-commits Differential Revision: https://reviews.llvm.org/D31118 llvm-svn: 298201
* [Analysis] Add LibFunc_ prefix to enums in TargetLibraryInfo. (NFC)David L. Jones2017-01-231-88/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ConstantFolding] Constant-fold llvm.sqrt(x) like other intrinsics.Justin Lebar2017-01-211-13/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Currently we return undef, but we're in the process of changing the LangRef so that llvm.sqrt behaves like the other math intrinsics, matching the return value of the standard libcall but not setting errno. This change is legal even without the LangRef change because currently calling llvm.sqrt(x) where x is negative is spec'ed to be UB. But in practice it's also safe because we're simply constant-folding fewer inputs: Inputs >= -0 get constant-folded as before, but inputs < -0 now aren't constant-folded, because ConstantFoldFP aborts if the host math function raises an fp exception. Reviewers: hfinkel, efriedma, sanjoy Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28929 llvm-svn: 292692
* [InstCombiner] Simplify lib calls to `round{,f}`Bryant Wong2016-12-261-0/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D28110 llvm-svn: 290542
* [ConstantFolding] Fix vector GEPs harderMichael Kuperstein2016-12-211-3/+6
| | | | | | | | | | For vector GEPs, CastGEPIndices can end up in an infinite recursion, because we compare the vector type to the scalar pointer type, find them different, and then try to cast a type to itself. Differential Revision: https://reviews.llvm.org/D28009 llvm-svn: 290260
* Replace APFloatBase static fltSemantics data members with getter functionsStephan Bergmann2016-12-141-4/+4
| | | | | | | | | | | | | 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
* ConstantFolding: Don't crash when encountering vector GEPKeno Fischer2016-12-081-3/+4
| | | | | | | | | | | | | | ConstantFolding tried to cast one of the scalar indices to a vector type. Instead, use the vector type only for the first index (which is the only one allowed to be a vector) and use its scalar type otherwise. Fixes PR31250. Reviewers: majnemer Differential Revision: https://reviews.llvm.org/D27389 llvm-svn: 289073
* InstCombine: Fold bitcast of vector to FP scalarMatt Arsenault2016-12-071-23/+25
| | | | llvm-svn: 288978
* ConstantFolding: Factor code into helper functionMatt Arsenault2016-12-021-23/+34
| | | | llvm-svn: 288459
* Analysis: gep inbounds (gep inbounds (...)) is inbounds.Peter Collingbourne2016-11-221-2/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D26441 llvm-svn: 287604
* IR: Introduce inrange attribute on getelementptr indices.Peter Collingbourne2016-11-101-9/+31
| | | | | | | | | | | | | | | | | If the inrange keyword is present before any index, loading from or storing to any pointer derived from the getelementptr has undefined behavior if the load or store would access memory outside of the bounds of the element selected by the index marked as inrange. This can be used, e.g. for alias analysis or to split globals at element boundaries where beneficial. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-July/102472.html Differential Revision: https://reviews.llvm.org/D22793 llvm-svn: 286514
* DCE math library calls with a constant operand.Eli Friedman2016-11-021-0/+149
| | | | | | | | | | | On platforms which use -fmath-errno, math libcalls without any uses require some extra checks to figure out if they are actually dead. Fixes https://llvm.org/bugs/show_bug.cgi?id=30464 . Differential Revision: https://reviews.llvm.org/D25970 llvm-svn: 285857
* [ConstantFold] Improve the bitcast folding logic for constant vectors.Andrea Di Biagio2016-09-131-2/+13
| | | | | | | | | | | | | | | | | | | | The constant folder didn't know how to always fold bitcasts of constant integer vectors. In particular, it was unable to handle the case where a constant vector had some undef elements, and the resulting (i.e. bitcasted) vector type had more elements than the original vector type. Example: %cast = bitcast <2 x i64><i64 undef, i64 2> to <4 x i32> On a little endian target, %cast could have been folded to: <4 x i32><i32 undef, i32 undef, i32 2, i32 0> This patch improves the folding logic by teaching how to correctly propagate undef elements in the folded vector. Differential Revision: https://reviews.llvm.org/D24301 llvm-svn: 281343
* Fix some Clang-tidy modernize-use-using and Include What You Use warnings; ↵Eugene Zelenko2016-08-251-6/+15
| | | | | | | | other minor fixes. Differential revision: https://reviews.llvm.org/D23861 llvm-svn: 279695
* [ConstantFolding] Don't create illegal (non-integral) inttoptrsSanjoy Das2016-08-051-3/+4
| | | | | | | | | | Reviewers: majnemer, arsenm Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D23182 llvm-svn: 277854
* [ConstantFolding] Handle bitcasts of undef fp vector elementsDavid Majnemer2016-07-291-1/+1
| | | | | | | | | We used the wrong type for constructing a zero vector element which led to type mismatches. This fixes PR28771. llvm-svn: 277197
* [ConstantFolding] Fold bitcasts of vectors w/ undef elementsDavid Majnemer2016-07-291-2/+11
| | | | | | | | An undef vector element can be treated as if it had any value. Folding such a vector element to 0 in a bitcast can open up further folding opportunities. llvm-svn: 277104
* [ConstantFolding] Remove an unused ConstantFoldInstOperands overloadDavid Majnemer2016-07-291-14/+5
| | | | | | No functional change is intended. llvm-svn: 277101
* [ConstantFolding] Use ConstantExpr::getWithOperandsDavid Majnemer2016-07-291-0/+3
| | | | | | | | | ConstantExpr::getWithOperands does much of the hard work that ConstantFoldInstOperandsImpl tries to do but more completely. This lets us fold ExtractValue/InsertValue expressions. llvm-svn: 277100
* [ConstnatFolding] Teach the folder how to fold ConstantVectorDavid Majnemer2016-07-291-57/+60
| | | | | | | | | | | A ConstantVector can have ConstantExpr operands and vice versa. However, the folder had no ability to fold ConstantVectors which, in some cases, was an optimization barrier. Instead, rephrase the folder in terms of Constants instead of ConstantExprs and teach callers how to deal with failure. llvm-svn: 277099
* [ConstantFolding] Don't bail on folding if ConstantFoldConstantExpression failsDavid Majnemer2016-07-281-19/+23
| | | | | | | | | | | | When folding an expression, we run ConstantFoldConstantExpression on each operand of that expression. However, ConstantFoldConstantExpression can fail and retur nullptr. Previously, we would bail on further refining the expression. Instead, use the original operand and see if we can refine a later operand. llvm-svn: 276959
* [ConstantFolding] Correctly handle failures in ↵David Majnemer2016-07-271-4/+13
| | | | | | | | | | | ConstantFoldConstantExpressionImpl Failures in ConstantFoldConstantExpressionImpl were ignored causing crashes down the line. This fixes PR28725. llvm-svn: 276827
* [X86][SSE] Reimplement SSE fp2si conversion intrinsics instead of using ↵Simon Pilgrim2016-07-191-9/+10
| | | | | | | | | | | | | | | | | | generic IR D20859 and D20860 attempted to replace the SSE (V)CVTTPS2DQ and VCVTTPD2DQ truncating conversions with generic IR instead. It turns out that the behaviour of these intrinsics is different enough from generic IR that this will cause problems, INF/NAN/out of range values are guaranteed to result in a 0x80000000 value - which plays havoc with constant folding which converts them to either zero or UNDEF. This is also an issue with the scalar implementations (which were already generic IR and what I was trying to match). This patch changes both scalar and packed versions back to using x86-specific builtins. It also deals with the other scalar conversion cases that are runtime rounding mode dependent and can have similar issues with constant folding. A companion clang patch is at D22105 Differential Revision: https://reviews.llvm.org/D22106 llvm-svn: 275981
* Simplify llvm.masked.load w/ undef masksDavid Majnemer2016-07-141-14/+21
| | | | | | | We can always pick the passthru value if the mask is undef: we are permitted to treat the mask as-if it were filled with zeros. llvm-svn: 275379
* [ConstantFolding] Fold masked loadsDavid Majnemer2016-07-141-1/+36
| | | | | | | | | We can constant fold a masked load if the operands are appropriately constant. Differential Revision: http://reviews.llvm.org/D22324 llvm-svn: 275352
* [ConstantFolding] Extend FoldReinterpretLoadFromConstPtr to handle negative ↵David Majnemer2016-07-131-10/+20
| | | | | | | | | offsets Treat loads which clip before the start of a global initializer the same way we treat clipping beyond the end of the initializer: use zeros. llvm-svn: 275345
* [ConstantFolding] Use sdiv_ovDavid Majnemer2016-07-131-4/+4
| | | | | | This is a simplification, there should be no functional change. llvm-svn: 275273
* [ConstantFolding] Don't treat negative GEP offsets as positiveDavid Majnemer2016-07-131-4/+7
| | | | | | GEP offsets are signed, don't treat them as huge positive numbers. llvm-svn: 275251
* [ConstantFolding] CleanupsDavid Majnemer2016-07-131-67/+66
| | | | | | No functional change is intended, just a minor cleanup. llvm-svn: 275249
* [IR] Make getIndexedOffsetInType return a signed resultDavid Majnemer2016-07-131-1/+1
| | | | | | | A GEPed offset can go negative, the result of getIndexedOffsetInType should according be a signed type. llvm-svn: 275246
* [ConstantFolding] Fix bitcast vector of i1.Igor Breger2016-06-271-1/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D21735 llvm-svn: 273845
* Replace silly uses of 'signed' with 'int'David Majnemer2016-06-211-7/+6
| | | | llvm-svn: 273244
* [ConstantFolding, ValueTracking] Fold constants involving bitcasts of ↵David Majnemer2016-05-041-7/+10
| | | | | | | | | | | | | | | | | ConstantVector We assumed that ConstantVectors would be rather uninteresting from the perspective of analysis. However, this is not the case due to a quirk of how LLVM handles vectors of i1. Vectors of i1 are not ConstantDataVectors like vectors of i8, i16, i32 or i64 because i1's SizeInBits differs from it's StoreSizeInBytes. This leads to it being categorized as a ConstantVector instead of a ConstantDataVector. Instead, treat ConstantVector more uniformly. This fixes PR27591. llvm-svn: 268479
* CodeGen: Use PLT relocations for relative references to unnamed_addr functions.Peter Collingbourne2016-04-221-2/+6
| | | | | | | | | | | | | The relative vtable ABI (PR26723) needs PLT relocations to refer to virtual functions defined in other DSOs. The unnamed_addr attribute means that the function's address is not significant, so we're allowed to substitute it with the address of a PLT entry. Also includes a bonus feature: addends for COFF image-relative references. Differential Revision: http://reviews.llvm.org/D17938 llvm-svn: 267211
* Propagate Undef in llvm.cos IntrinsicSanjoy Das2016-04-081-0/+5
| | | | | | | | | | | | | | | | | | Summary: The llvm cos intrinsic currently does not propagate undef's. This change transforms cos(undef) to null value or 0. There are 2 test cases added as well. Patch by Anna Thomas! Reviewers: sanjoy Subscribers: majnemer, llvm-commits Differential Revision: http://reviews.llvm.org/D18863 llvm-svn: 265825
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
* Fix Clang-tidy modernize-deprecated-headers warnings in some files; other ↵Eugene Zelenko2016-03-281-61/+63
| | | | | | | | minor fixes. Differential revision: http://reviews.llvm.org/D18469 llvm-svn: 264598
* Implement constant folding for bitreverseMatt Arsenault2016-03-211-0/+3
| | | | llvm-svn: 263945
* Re-add ConstantFoldInstOperands form taking opcode and return type.Manuel Jacob2016-03-141-4/+13
| | | | | | | | | | | | | | | | | | | | | | | Summary: This form was replaced by a form taking an instruction instead of opcode and return type in r258391. After committing this change (and some depending, follow-up changes) it turned out in the review thread to be controversial. The discussion didn't come to a conclusion yet. I'm re-adding the old form to fix the API regression and to provide a better base for discussion, possibly on llvm-dev. A difference to the original function is that it can't be called with GEPs (similarly to how it was already the case for compares). In order to support opaque pointers in the future, folding GEPs needs to be passed the source element type, which is not possible with the current API. Reviewers: dberlin, reames Subscribers: dblaikie, eddyb Differential Revision: http://reviews.llvm.org/D17901 llvm-svn: 263501
* ConstantFoldInstruction: avoid wasted calls to ConstantFoldConstantExpressionFiona Glaser2016-03-131-5/+5
| | | | | | | Check to see if all operands are constant before calling simplify on them so that we don't perform wasted simplifications. llvm-svn: 263374
* [ConstantFolding] Reduce APInt and APFloat copying.Benjamin Kramer2016-02-131-1/+1
| | | | llvm-svn: 260826
* Remove duplicate documentation in ConstantFolding.cpp. NFC.Manuel Jacob2016-01-231-22/+0
| | | | | | The documentation for these functions is already present in the header file. llvm-svn: 258649
OpenPOWER on IntegriCloud