summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/ConstantFold.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-1/+1
| | | | | | | 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
* [ConstantFold] Don't incorrectly infer inbounds on array GEPDavid Majnemer2016-07-131-42/+59
| | | | | | | | The many levels of nesting inside the responsible code made it easy for bugs to sneak in. Flattening the logic makes it easier to see what's going on. llvm-svn: 275244
* [ConstantFold] NFC cleanup after previous change.Adam Nemet2016-05-261-40/+39
| | | | | | Merge two conditions. llvm-svn: 270827
* [ConstantFold] Fix incorrect index rewrites for GEPsAdam Nemet2016-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If an index for a vector or array type is out-of-range GEP constant folding tries to factor it into preceding dimensions. The code however does not consider addressing of structure field padding which should not qualify as out-of-range index. As demonstrated by the testcase, this can occur if the indexing performed on a vector type and the preceding index is an array type. SROA generates GEPs for example involving padding bytes as it slices an alloca. My fix disables this folding if the element type is a vector type. I believe that this is the only way we can end up with padding. (We have no access to DataLayout so I am not sure if there is actual robust way of actually checking the presence of padding.) Reviewers: majnemer Subscribers: llvm-commits, Gerolf Differential Revision: http://reviews.llvm.org/D20663 llvm-svn: 270826
* Fix constant folding of addrspacecast of nullMatt Arsenault2016-05-211-1/+2
| | | | | | | This should not be making assumptions on the value of the casted pointer. llvm-svn: 270293
* [ConstantFold] Don't try to strip fp -> int bitcasts to simplify icmpsHal Finkel2016-05-041-0/+4
| | | | | | | | | | | | | ConstantFold has logic to take icmp (bitcast x to y), null and strip the bitcast. This makes sense in general, but not if x has floating-point type. In this case, we'd need a fcmp, not an icmp, and the code will assert. We normally don't see this situation because we constant fold fp -> int bitcasts, however, we'll see it for bitcasts of ppc_fp128 -> i128. This is because that bitcast is Endian-dependent, and as a result, we don't simplify it in ConstantFold (we could, but no one has yet added the necessary logic). Regardless, ConstantFold should not depend on that canonicalization for correctness. llvm-svn: 268534
* [NFC] Header cleanupMehdi Amini2016-04-181-2/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* fix documentation comments; NFCSanjay Patel2016-04-051-39/+34
| | | | llvm-svn: 265434
* Don't fold double constant to an integer if dest type not integralTeresa Johnson2016-04-041-0/+4
| | | | | | | | | | | | | | Summary: I encountered this issue when constant folding during inlining tried to fold away a bitcast of a double to an x86_mmx, which is not an integral type. The test case exposes the same issue with a smaller code snippet during early CSE. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D18528 llvm-svn: 265367
* [InstCombine] Ensure all undef operands are handled before binary ↵Simon Pilgrim2016-03-211-2/+16
| | | | | | | | | | instruction constant folding As noted in PR18355, this patch makes it clear that all cases with undef operands have been handled before further constant folding is attempted. Differential Revision: http://reviews.llvm.org/D18305 llvm-svn: 263994
* Strip trailing whitespace.Simon Pilgrim2016-03-101-66/+66
| | | | llvm-svn: 263162
* IR: Make the X / undef -> undef fold match the commentJustin Bogner2016-02-251-1/+1
| | | | | | | | | | | | | | | | The constant folding for sdiv and udiv has a big discrepancy between the comments and the code, which looks like a typo. Currently, we're folding X / undef pretty inconsistently: 0 / undef -> undef C / undef -> 0 undef / undef -> 0 Whereas the comments state we do X / undef -> undef. The logic that returns zero is actually commented as doing undef / X -> 0, despite that the LHS isn't undef in many of the cases that hit it. llvm-svn: 261813
* [ConstantFolding] Reduce APInt and APFloat copying.Benjamin Kramer2016-02-131-7/+7
| | | | llvm-svn: 260826
* [opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with ↵Eduard Burtescu2016-01-191-19/+3
| | | | | | | | | | | | | | | | | | get{Source,Result}ElementType. Summary: GEPOperator: provide getResultElementType alongside getSourceElementType. This is made possible by adding a result element type field to GetElementPtrConstantExpr, which GetElementPtrInst already has. GEP: replace get(Pointer)ElementType uses with get{Source,Result}ElementType. Reviewers: mjacob, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16275 llvm-svn: 258145
* Fix constant folding of constant vector GEPs with undef or null as pointer ↵Manuel Jacob2016-01-191-9/+13
| | | | | | | | | | | | argument. Reviewers: eddyb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16321 llvm-svn: 258134
* Rename Variable `Ptr` to `PtrTy`. NFC.Manuel Jacob2016-01-191-6/+6
| | | | llvm-svn: 258130
* Use CmpInst::Predicate instead of 'unsigned short' in some places. NFCCraig Topper2015-12-151-4/+7
| | | | llvm-svn: 255623
* [ConstantFold] Fix bitcast to gep constant folding transform.David Majnemer2015-12-141-1/+1
| | | | | | | | | | | | Make sure to check that the destination type is sized. A check was present but was incorrectly checking the source type instead. Patch by Amaury SECHET! Differential Revision: http://reviews.llvm.org/D15264 llvm-svn: 255536
* Remove roundingMode argument in APFloat::modStephen Canon2015-09-211-1/+1
| | | | | | Because mod is always exact, this function should have never taken a rounding mode argument. The actual implementation still has issues, which I'll look at resolving in a subsequent patch. llvm-svn: 248195
* Fix typos.Bruce Mitchener2015-09-121-4/+4
| | | | | | | | | | Summary: This fixes a variety of typos in docs, code and headers. Subscribers: jholewinski, sanjoy, arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12626 llvm-svn: 247495
* Add comment as follow up to r245712David Blaikie2015-08-211-0/+1
| | | | llvm-svn: 245730
* Remove an unnecessary use of pointee types introduced in r194220David Blaikie2015-08-211-3/+2
| | | | | | | | David Majnemer (the original author) believes this to be an impossible condition to reach anyway, and no test cases cover this so we'll go with that. llvm-svn: 245712
* De-constify pointers to Type since they can't be modified. NFCCraig Topper2015-08-011-5/+5
| | | | | | This was already done in most places a while ago. This just fixes the ones that crept in over time. llvm-svn: 243842
* Refix a use of explicit pointer types in GEP constant foldingDavid Blaikie2015-06-121-4/+4
| | | | | | | | | | | | | | | | | In the glorious future of opaque pointer types, it won't be possible to retrieve the pointee type of a pointer type which is what's being done in this GEP loop - but the first iteration is always a pointer type and the loop doesn't care about that case, except whether or not the index is a constant. So pull that special case out before the loop and start at the second iteration (index 1) instead. Originally committed in r236670 and reverted with a test case in r239015. This change keeps the test case working while also avoiding depending on pointee types. llvm-svn: 239629
* [ConstantFold] Don't skip the first gep index when folding gepsDavid Majnemer2015-06-041-3/+3
| | | | | | | | | We neglected to check if the first index made the GEP ineligible for 'inbounds'. This fixes PR23753. llvm-svn: 239015
* [opaque pointer type] Pass explicit pointee type in another case of GEP ↵David Blaikie2015-05-211-1/+1
| | | | | | constant folding llvm-svn: 237860
* As r237678 was reverted, this is no longer needed.Yaron Keren2015-05-191-2/+1
| | | | llvm-svn: 237687
* Fix Visual C++ errors C2784, C2780, C2782 after r237678.Yaron Keren2015-05-191-1/+2
| | | | | | It does not like std::min(unsigned, uint32_t). llvm-svn: 237683
* [opaque pointer type] Use GlobalVariable::getValueType rather than accessing ↵David Blaikie2015-05-131-1/+1
| | | | | | it through the GV's pointee type llvm-svn: 237311
* [opaque pointer type] Constant Folding: Use GEPOperator to access the ↵David Blaikie2015-05-131-2/+2
| | | | | | pointee source type rather than going through the first operand's pointer type llvm-svn: 237274
* Recommit r236670: [opaque pointer type] Pass explicit pointer type through ↵David Blaikie2015-05-071-7/+23
| | | | | | | | | | GEP constant folding"" Clang regressions were caused by more stringent assertion checking introduced by this change. Small fix needed to clang has been committed in r236751. llvm-svn: 236752
* Revert "[opaque pointer type] Pass explicit pointer type through GEP ↵David Blaikie2015-05-061-23/+7
| | | | | | | | | | constant folding" Causes regressions in Clang. Reverting while I investigate. This reverts commit r236670. llvm-svn: 236678
* [opaque pointer type] Pass explicit pointer type through GEP constant foldingDavid Blaikie2015-05-061-7/+23
| | | | llvm-svn: 236670
* Constfold insertelement to undef when index is out-of-boundsPawel Bylica2015-04-271-7/+14
| | | | | | | | | | | | | | | | | | | Summary: This patch adds constant folding of insertelement instruction to undef value when index operand is constant and is not less than vector size or is undef. InstCombine does not support this case, but I'm happy to add it there also if this change is accepted. Test Plan: Unittests and regression tests for ConstProp pass. Reviewers: majnemer Reviewed By: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9287 llvm-svn: 235854
* Correct extractelement constant foldingPawel Bylica2015-04-241-3/+2
| | | | | | | | | | | | | | | | Summary: Constant folding of extractelement with out-of-bound index produces undef also for indexes bigger than 64bit (instead of crash assert failure as before) Test Plan: Unit tests included. Reviewers: majnemer Reviewed By: majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9225 llvm-svn: 235700
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-021-9/+9
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* [opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie2015-03-301-2/+4
| | | | | | | | | | pointee type This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it... llvm-svn: 233604
* [ConstantFold] Don't fold ppc_fp128 <-> int bitcastsHal Finkel2015-03-281-2/+13
| | | | | | | | | | | | | PPC_FP128 is really the sum of two consecutive doubles, where the first double is always stored first in memory, regardless of the target endianness. The memory layout of i128, however, depends on the target endianness, and so we can't fold this without target endianness information. As a result, we must not do this folding in lib/IR/ConstantFold.cpp (it could be done instead in Analysis/ConstantFolding.cpp, but that's not done now). Fixes PR23026. llvm-svn: 233481
* ConstantFold: Fix big shift constant foldingDavid Majnemer2015-03-131-21/+12
| | | | | | | | | | | | | Constant folding for shift IR instructions ignores all bits above 32 of second argument (shift amount). Because of that, some undef results are not recognized and APInt can raise an assert failure if second argument has more than 64 bits. Patch by Paweł Bylica! Differential Revision: http://reviews.llvm.org/D7701 llvm-svn: 232176
* InstCombine: fix fold "fcmp x, undef" to account for NaNMehdi Amini2015-03-091-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | Summary: See the two test cases. ; Can fold fcmp with undef on one side by choosing NaN for the undef ; Can fold fcmp with undef on both side ; fcmp u_pred undef, undef -> true ; fcmp o_pred undef, undef -> false ; because whatever you choose for the first undef ; you can choose NaN for the other undef Reviewers: hfinkel, chandlerc, majnemer Reviewed By: majnemer Subscribers: majnemer, llvm-commits Differential Revision: http://reviews.llvm.org/D7617 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231626
* Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer2015-02-171-2/+1
| | | | | | Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
* ConstantFold: Properly fold GEP indices wider than i64David Majnemer2015-02-161-18/+31
| | | | llvm-svn: 229420
* ConstantFold: Shifting undef by zero results in undefDavid Majnemer2014-12-181-0/+9
| | | | llvm-svn: 224553
* ConstantFold: Clean up X * undef codeDavid Majnemer2014-12-101-6/+8
| | | | | | No functional change intended. llvm-svn: 223970
* ConstantFold, InstSimplify: undef >>a x can be either -1 or 0, choose 0David Majnemer2014-12-101-2/+3
| | | | | | Zero is usually a nicer constant to have than -1. llvm-svn: 223969
* ConstantFold: an undef shift amount results in undefDavid Majnemer2014-12-101-13/+14
| | | | | | | X shifted by undef results in undef because the undef value can represent values greater than the width of the operands. llvm-svn: 223968
* ConstantFold: div undef, 0 should fold to undef, not zeroDavid Majnemer2014-12-101-9/+19
| | | | | | Dividing by zero yields an undefined value. llvm-svn: 223924
* ConstantFold: Zero-sized globals might land on top of another globalDavid Majnemer2014-12-081-3/+15
| | | | | | | A zero sized array is zero sized and might share its address with another global. llvm-svn: 223684
* ConstantFold: Don't optimize comparisons with weak linkage objectsDavid Majnemer2014-12-061-1/+4
| | | | | | | | | | | | Consider: void f() {} void __attribute__((weak)) g() {} bool b = &f != &g; It's possble for g to resolve to f if --defsym=g=f is passed on to the linker. llvm-svn: 223585
* I didn't intend to commit this change.David Majnemer2014-12-061-1/+1
| | | | llvm-svn: 223584
OpenPOWER on IntegriCloud