aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/IR/ConstantFold.cpp
AgeCommit message (Collapse)AuthorFilesLines
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
2014-12-06InstSimplify: Optimize away useless unsigned comparisonsDavid Majnemer1-1/+1
Code like X < Y && Y == 0 should always be folded away to false. llvm-svn: 223583
2014-10-10Return undef on FP <-> Int conversions that overflow (PR21330).Sanjay Patel1-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
2014-08-21Fix a bug around truncating vector in const prop.Jiangning Liu1-0/+3
In constant folding stage, "TRUNC" can't handle vector data type. llvm-svn: 216149
2014-08-16IR: Don't add inbounds to GEPs of extern_weak variablesDuncan P. N. Exon Smith1-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
2014-07-04IR: Fold away compares between GV GEPs and GVsDavid Majnemer1-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
2014-06-15Canonicalize addrspacecast ConstExpr between different pointer typesJingyue Wu1-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
2014-04-15[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper1-2/+2
instead of comparing to nullptr. llvm-svn: 206252
2014-04-09[C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper1-52/+52
check instead of comparing to nullptr. llvm-svn: 205831
2014-03-04[Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth1-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
2013-12-31Fold vector selects with undef elements in the condition. Fixes PR18319.Nick Lewycky1-6/+15
Patch by Ilia Filippov! llvm-svn: 198267
2013-11-15Add addrspacecast instruction.Matt Arsenault1-0/+2
Patch by Michele Scandale! llvm-svn: 194760
2013-11-10IR: Refactor GEP range checks, reuse them for other parts of foldingDavid Majnemer1-28/+51
llvm-svn: 194341
2013-11-07IR: Properly canonicalize PointerType in ConstantExpr GEPsDavid Majnemer1-5/+6
No additional test was needed, Other/constant-fold-gep.ll detects this just fine. llvm-svn: 194221
2013-11-07IR: Do not canonicalize constant GEPs into an out-of-bounds array accessDavid Majnemer1-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
2013-07-30Respect address space sizes in isEliminableCastPair.Matt Arsenault1-4/+5
This avoids constant folding bitcast/ptrtoint/inttoptr combinations that have illegal bitcasts between differently sized address spaces. llvm-svn: 187455
2013-06-30ConstantFold: Check that truncating the other side is safe under a sext when ↵Benjamin Kramer1-2/+2
trying to remove a sext from a compare. Fixes PR16462. llvm-svn: 185284
2013-02-27IR: Don't constant fold GEP bitcasts between different address spacesMeador Inge1-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
2013-02-19Fix a bug that was found by the clang static analyzer. The var "AT" is null ↵Nadav Rotem1-2/+2
so we cant deref it. llvm-svn: 175550
2013-01-31Fix ConstantFold's folding of icmp instructions to recognize that,Dan Gohman1-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
2013-01-22Make APFloat constructor require explicit semantics.Tim Northover1-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
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth1-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
2013-01-02Rename VMCore directory to IR.Chandler Carruth1-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
generated by cgit v1.1 at 2025-10-17 11:00:43 +0000