aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/ConstantFold.cpp
AgeCommit message (Collapse)AuthorFilesLines
2016-08-17Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner1-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
2016-07-13[ConstantFold] Don't incorrectly infer inbounds on array GEPDavid Majnemer1-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
2016-05-26[ConstantFold] NFC cleanup after previous change.Adam Nemet1-40/+39
Merge two conditions. llvm-svn: 270827
2016-05-26[ConstantFold] Fix incorrect index rewrites for GEPsAdam Nemet1-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
2016-05-21Fix constant folding of addrspacecast of nullMatt Arsenault1-1/+2
This should not be making assumptions on the value of the casted pointer. llvm-svn: 270293
2016-05-04[ConstantFold] Don't try to strip fp -> int bitcasts to simplify icmpsHal Finkel1-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
2016-04-18[NFC] Header cleanupMehdi Amini1-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
2016-04-05fix documentation comments; NFCSanjay Patel1-39/+34
llvm-svn: 265434
2016-04-04Don't fold double constant to an integer if dest type not integralTeresa Johnson1-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
2016-03-21[InstCombine] Ensure all undef operands are handled before binary ↵Simon Pilgrim1-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
2016-03-10Strip trailing whitespace.Simon Pilgrim1-66/+66
llvm-svn: 263162
2016-02-25IR: Make the X / undef -> undef fold match the commentJustin Bogner1-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
2016-02-13[ConstantFolding] Reduce APInt and APFloat copying.Benjamin Kramer1-7/+7
llvm-svn: 260826
2016-01-19[opaque pointer types] [NFC] GEP: replace get(Pointer)ElementType uses with ↵Eduard Burtescu1-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
2016-01-19Fix constant folding of constant vector GEPs with undef or null as pointer ↵Manuel Jacob1-9/+13
argument. Reviewers: eddyb Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16321 llvm-svn: 258134
2016-01-19Rename Variable `Ptr` to `PtrTy`. NFC.Manuel Jacob1-6/+6
llvm-svn: 258130
2015-12-15Use CmpInst::Predicate instead of 'unsigned short' in some places. NFCCraig Topper1-4/+7
llvm-svn: 255623
2015-12-14[ConstantFold] Fix bitcast to gep constant folding transform.David Majnemer1-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
2015-09-21Remove roundingMode argument in APFloat::modStephen Canon1-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
2015-09-12Fix typos.Bruce Mitchener1-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
2015-08-21Add comment as follow up to r245712David Blaikie1-0/+1
llvm-svn: 245730
2015-08-21Remove an unnecessary use of pointee types introduced in r194220David Blaikie1-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
2015-08-01De-constify pointers to Type since they can't be modified. NFCCraig Topper1-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
2015-06-12Refix a use of explicit pointer types in GEP constant foldingDavid Blaikie1-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
2015-06-04[ConstantFold] Don't skip the first gep index when folding gepsDavid Majnemer1-3/+3
We neglected to check if the first index made the GEP ineligible for 'inbounds'. This fixes PR23753. llvm-svn: 239015
2015-05-21[opaque pointer type] Pass explicit pointee type in another case of GEP ↵David Blaikie1-1/+1
constant folding llvm-svn: 237860
2015-05-19As r237678 was reverted, this is no longer needed.Yaron Keren1-2/+1
llvm-svn: 237687
2015-05-19Fix Visual C++ errors C2784, C2780, C2782 after r237678.Yaron Keren1-1/+2
It does not like std::min(unsigned, uint32_t). llvm-svn: 237683
2015-05-13[opaque pointer type] Use GlobalVariable::getValueType rather than accessing ↵David Blaikie1-1/+1
it through the GV's pointee type llvm-svn: 237311
2015-05-13[opaque pointer type] Constant Folding: Use GEPOperator to access the ↵David Blaikie1-2/+2
pointee source type rather than going through the first operand's pointer type llvm-svn: 237274
2015-05-07Recommit r236670: [opaque pointer type] Pass explicit pointer type through ↵David Blaikie1-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
2015-05-06Revert "[opaque pointer type] Pass explicit pointer type through GEP ↵David Blaikie1-23/+7
constant folding" Causes regressions in Clang. Reverting while I investigate. This reverts commit r236670. llvm-svn: 236678
2015-05-06[opaque pointer type] Pass explicit pointer type through GEP constant foldingDavid Blaikie1-7/+23
llvm-svn: 236670
2015-04-27Constfold insertelement to undef when index is out-of-boundsPawel Bylica1-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
2015-04-24Correct extractelement constant foldingPawel Bylica1-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
2015-04-02[opaque pointer type] API migration for GEP constant factoriesDavid Blaikie1-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
2015-03-30[opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie1-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
2015-03-28[ConstantFold] Don't fold ppc_fp128 <-> int bitcastsHal Finkel1-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
2015-03-13ConstantFold: Fix big shift constant foldingDavid Majnemer1-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
2015-03-09InstCombine: fix fold "fcmp x, undef" to account for NaNMehdi Amini1-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
2015-02-17Prefer SmallVector::append/insert over push_back loops.Benjamin Kramer1-2/+1
Same functionality, but hoists the vector growth out of the loop. llvm-svn: 229500
2015-02-16ConstantFold: Properly fold GEP indices wider than i64David Majnemer1-18/+31
llvm-svn: 229420
2014-12-18ConstantFold: Shifting undef by zero results in undefDavid Majnemer1-0/+9
llvm-svn: 224553
2014-12-10ConstantFold: Clean up X * undef codeDavid Majnemer1-6/+8
No functional change intended. llvm-svn: 223970
2014-12-10ConstantFold, InstSimplify: undef >>a x can be either -1 or 0, choose 0David Majnemer1-2/+3
Zero is usually a nicer constant to have than -1. llvm-svn: 223969
2014-12-10ConstantFold: an undef shift amount results in undefDavid Majnemer1-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
2014-12-10ConstantFold: div undef, 0 should fold to undef, not zeroDavid Majnemer1-9/+19
Dividing by zero yields an undefined value. llvm-svn: 223924
2014-12-08ConstantFold: Zero-sized globals might land on top of another globalDavid Majnemer1-3/+15
A zero sized array is zero sized and might share its address with another global. llvm-svn: 223684
2014-12-06ConstantFold: Don't optimize comparisons with weak linkage objectsDavid Majnemer1-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
2014-12-06I didn't intend to commit this change.David Majnemer1-1/+1
llvm-svn: 223584
generated by cgit v1.1 at 2025-10-14 06:15:33 +0000