summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/ConstantFold.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* Fix a bug that was found by the clang static analyzer. The var "AT" is null ↵Nadav Rotem2013-02-191-2/+2
| | | | | | so we cant deref it. llvm-svn: 175550
* Fix ConstantFold's folding of icmp instructions to recognize that,Dan Gohman2013-01-311-6/+5
| | | | | | | for example, a one-past-the-end pointer from one global variable may be equal to the base pointer of another global variable. llvm-svn: 173995
* Make APFloat constructor require explicit semantics.Tim Northover2013-01-221-4/+4
| | | | | | | | | Previously we tried to infer it from the bit width size, with an added IsIEEE argument for the PPC/IEEE 128-bit case, which had a default value. This default value allowed bugs to creep in, where it was inappropriate. llvm-svn: 173138
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-7/+7
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* Rename VMCore directory to IR.Chandler Carruth2013-01-021-0/+2066
Aside from moving the actual files, this patch only updates the build system and the source file comments under lib/... that are relevant. I'll be updating other docs and other files in smaller subsequnet commits. While I've tried to test this, but it is entirely possible that there will still be some build system fallout. Also, note that I've not changed the library name itself: libLLVMCore.a is still the library name. I'd be interested in others' opinions about whether we should rename this as well (I think we should, just not sure what it might break) llvm-svn: 171359
OpenPOWER on IntegriCloud