summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/ConstantFold.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* InstSimplify: Optimize away useless unsigned comparisonsDavid Majnemer2014-12-061-1/+1
| | | | | | Code like X < Y && Y == 0 should always be folded away to false. llvm-svn: 223583
* Return undef on FP <-> Int conversions that overflow (PR21330).Sanjay Patel2014-10-101-5/+14
| | | | | | | | | | | | | | | | | | | | The LLVM Lang Ref states for signed/unsigned int to float conversions: "If the value cannot fit in the floating point value, the results are undefined." And for FP to signed/unsigned int: "If the value cannot fit in ty2, the results are undefined." This matches the C definitions. The existing behavior pins to infinity or a max int value, but that may just lead to more confusion as seen in: http://llvm.org/bugs/show_bug.cgi?id=21130 Returning undef will hopefully lead to a less silent failure. Differential Revision: http://reviews.llvm.org/D5603 llvm-svn: 219542
* Fix a bug around truncating vector in const prop.Jiangning Liu2014-08-211-0/+3
| | | | | | In constant folding stage, "TRUNC" can't handle vector data type. llvm-svn: 216149
* IR: Don't add inbounds to GEPs of extern_weak variablesDuncan P. N. Exon Smith2014-08-161-3/+4
| | | | | | | | | | | | Global variables that have `extern_weak` linkage may be null, so it's incorrect to add `inbounds` when constant folding. This also fixes a bug when parsing global aliases, whose forward reference placeholders are global variables with `extern_weak` linkage. If GEPs to these aliases are encountered before the alias itself, the GEPs would incorrectly gain the `inbounds` keyword as well. llvm-svn: 215803
* IR: Fold away compares between GV GEPs and GVsDavid Majnemer2014-07-041-7/+22
| | | | | | | | | A GEP of a non-weak global variable will not be equivalent to another non-weak global variable or a GEP of such a variable. Differential Revision: http://reviews.llvm.org/D4238 llvm-svn: 212360
* Canonicalize addrspacecast ConstExpr between different pointer typesJingyue Wu2014-06-151-1/+4
| | | | | | | | | | | | | | | | | | As a follow-up to r210375 which canonicalizes addrspacecast instructions, this patch canonicalizes addrspacecast constant expressions. Given clang uses ConstantExpr::getAddrSpaceCast to emit addrspacecast cosntant expressions, this patch is also a step towards having the frontend emit canonicalized addrspacecasts. Piggyback a minor refactor in InstCombineCasts.cpp Update three affected tests in addrspacecast-alias.ll, access-non-generic.ll and constant-fold-gep.ll and added one new test in constant-fold-address-space-pointer.ll llvm-svn: 211004
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-2/+2
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-52/+52
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-041-1/+1
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
* Fold vector selects with undef elements in the condition. Fixes PR18319.Nick Lewycky2013-12-311-6/+15
| | | | | | Patch by Ilia Filippov! llvm-svn: 198267
* Add addrspacecast instruction.Matt Arsenault2013-11-151-0/+2
| | | | | | Patch by Michele Scandale! llvm-svn: 194760
* IR: Refactor GEP range checks, reuse them for other parts of foldingDavid Majnemer2013-11-101-28/+51
| | | | llvm-svn: 194341
* IR: Properly canonicalize PointerType in ConstantExpr GEPsDavid Majnemer2013-11-071-5/+6
| | | | | | | No additional test was needed, Other/constant-fold-gep.ll detects this just fine. llvm-svn: 194221
* IR: Do not canonicalize constant GEPs into an out-of-bounds array accessDavid Majnemer2013-11-071-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Consider a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0) If we proceeded to GEP the aforementioned object by 8, would form a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8) Note that we would go through the first array member, causing an out-of-bounds accesses. This is problematic because we might get fooled if we are trying to evaluate loads using this GEP, for example, based off of an object with a constant initializer where the array is zero. This fixes PR17732. Reviewers: nicholas, chandlerc, void Reviewed By: void CC: llvm-commits, echristo, void, aemerson Differential Revision: http://llvm-reviews.chandlerc.com/D2093 llvm-svn: 194220
* Respect address space sizes in isEliminableCastPair.Matt Arsenault2013-07-301-4/+5
| | | | | | | This avoids constant folding bitcast/ptrtoint/inttoptr combinations that have illegal bitcasts between differently sized address spaces. llvm-svn: 187455
* ConstantFold: Check that truncating the other side is safe under a sext when ↵Benjamin Kramer2013-06-301-2/+2
| | | | | | | | trying to remove a sext from a compare. Fixes PR16462. llvm-svn: 185284
* IR: Don't constant fold GEP bitcasts between different address spacesMeador Inge2013-02-271-13/+22
| | | | | | | | | | | | | | | | | | PR15262 reported a bug where the following instruction: i8 getelementptr inbounds i8* bitcast ([4 x i8] addrspace(12)* @buf to i8*), i32 2 was getting folded into: addrspace(12)* getelementptr inbounds ([4 x i8] addrspace(12)* @buf, i32 0, i32 2) This caused instcombine to crash because the original instruction and the folded instruction have different types. The issue was fixed by disallowing bitcasts between different address spaces to be folded away. llvm-svn: 176156
OpenPOWER on IntegriCloud