summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Replacing zero-sized alloca's with a null pointer is too aggressive, insteadDuncan Sands2012-06-261-8/+40
| | | | | | | | | | | | | | | | merge all zero-sized alloca's into one, fixing c43204g from the Ada ACATS conformance testsuite. What happened there was that a variable sized object was being allocated on the stack, "alloca i8, i32 %size". It was then being passed to another function, which tested that the address was not null (raising an exception if it was) then manipulated %size bytes in it (load and/or store). The optimizers cleverly managed to deduce that %size was zero (congratulations to them, as it isn't at all obvious), which made the alloca zero size, causing the optimizers to replace it with null, which then caused the check mentioned above to fail, and the exception to be raised, wrongly. Note that no loads and stores were actually being done to the alloca (the loop that does them is executed %size times, i.e. is not executed), only the not-null address check. llvm-svn: 159202
* Teach InstCombine to nuke a common alloca pattern -- an alloca which hasChandler Carruth2012-04-081-1/+70
| | | | | | | | | | | | GEPs, bit casts, and stores reaching it but no other instructions. These often show up during the iterative processing of the inliner, SROA, and DCE. Once we hit this point, we can completely remove the alloca. These were actually showing up in the final, fully optimized code in a bunch of inliner tests I've been working on, and notably they show up after LLVM finishes optimizing away all function calls involved in hash_combine(a, b). llvm-svn: 154285
* Revert r152907.Bill Wendling2012-03-161-15/+3
| | | | llvm-svn: 152935
* The alignment of the pointer part of the store instruction may have anBill Wendling2012-03-161-3/+15
| | | | | | | | | | alignment. If that's the case, then we want to make sure that we don't increase the alignment of the store instruction. Because if we increase it to be "more aligned" than the pointer, code-gen may use instructions which require a greater alignment than the pointer guarantees. <rdar://problem/11043589> llvm-svn: 152907
* Use the getFirstInsertionPt() method instead of getFirstNonPHI + an 'isa<>'Bill Wendling2011-08-161-2/+1
| | | | | | check for a LandingPadInst. llvm-svn: 137745
* A few places where we want to skip the landingpad instruction for insertion.Bill Wendling2011-08-161-0/+1
| | | | llvm-svn: 137712
* Update instcombine for atomic load/store.Eli Friedman2011-08-151-29/+32
| | | | llvm-svn: 137664
* Convert GetElementPtrInst to use ArrayRef.Jay Foad2011-07-251-2/+1
| | | | llvm-svn: 135904
* Convert IRBuilder::CreateGEP and IRBuilder::CreateInBoundsGEP to useJay Foad2011-07-221-2/+1
| | | | | | ArrayRef. llvm-svn: 135761
* Fix an MSVC warning, caused by a case I missed when convertingJay Foad2011-07-221-1/+1
| | | | | | ConstantExpr::getGetElementPtr to use ArrayRef. llvm-svn: 135758
* land David Blaikie's patch to de-constify Type, with a few tweaks.Chris Lattner2011-07-181-14/+14
| | | | llvm-svn: 135375
* Final step of instcombine debuginfo; switch a couple more places over to ↵Eli Friedman2011-05-271-4/+6
| | | | | | InsertNewInstWith, and use setDebugLoc for the cases which can't be easily handled by the automated mechanisms. llvm-svn: 132167
* More instcombine cleanup, towards improving debug line info.Eli Friedman2011-05-181-3/+5
| | | | llvm-svn: 131604
* Remove PHINode::reserveOperandSpace(). Instead, add a parameter toJay Foad2011-03-301-2/+1
| | | | | | PHINode::Create() giving the (known or expected) number of operands. llvm-svn: 128537
* This case is solved by Scalar Replacement of Aggregates (DT) andJin-Gu Kang2011-03-141-25/+3
| | | | | | Early CSE pass so this patch reverts it to original source code. llvm-svn: 127574
* Add comment as following:Jin-Gu Kang2011-03-131-0/+12
| | | | | | | | | | | | | | | | | load and store reference same memory location, the memory location is represented by getelementptr with two uses (load and store) and the getelementptr's base is alloca with single use. At this point, instructions from alloca to store can be removed. (this pattern is generated when bitfield is accessed.) For example, %u = alloca %struct.test, align 4 ; [#uses=1] %0 = getelementptr inbounds %struct.test* %u, i32 0, i32 0;[#uses=2] %1 = load i8* %0, align 4 ; [#uses=1] %2 = and i8 %1, -16 ; [#uses=1] %3 = or i8 %2, 5 ; [#uses=1] store i8 %3, i8* %0, align 4 llvm-svn: 127565
* This patch removes some of useless instructions generated by bitfield access.Jin-Gu Kang2011-03-121-3/+13
| | | | llvm-svn: 127539
* llvm.dbg.declare intrinsic does not use any llvm::Values. It's magic!Devang Patel2011-03-081-30/+0
| | | | llvm-svn: 127282
* Spelling fix: consequtive -> consecutive.Duncan Sands2011-02-151-1/+1
| | | | llvm-svn: 125563
* Move getOrEnforceKnownAlignment out of instcombine into Transforms/Utils.Chris Lattner2010-12-251-2/+3
| | | | llvm-svn: 122554
* Fix a case where instcombine was stripping metadata (and alignment)Dan Gohman2010-10-251-1/+3
| | | | | | from stores when folding in bitcasts. llvm-svn: 117265
* Remove r111665, which implemented store-narrowing in InstCombine. Chris ↵Owen Anderson2010-08-311-47/+0
| | | | | | | | discovered a miscompilation in it, and it's not easily fixable at the optimizer level. I'll investigate reimplementing it in DAGCombine. llvm-svn: 112575
* Re-apply r111568 with a fix for the clang self-host.Owen Anderson2010-08-201-0/+47
| | | | llvm-svn: 111665
* Revert r111568 to unbreak clang self-host.Owen Anderson2010-08-191-45/+0
| | | | llvm-svn: 111571
* When a set of bitmask operations, typically from a bitfield initialization, ↵Owen Anderson2010-08-191-0/+45
| | | | | | | | only modifies the low bytes of a value, we can narrow the store to only over-write the affected bytes. llvm-svn: 111568
* Make instcombine set explicit alignments on load or storeDan Gohman2010-08-031-6/+14
| | | | | | | instructions with alignment 0, so that subsequent passes don't need to bother checking the TargetData ABI size manually. llvm-svn: 110128
* mass elimination of reliance on automatic iterator dereferencingGabor Greif2010-07-221-1/+1
| | | | llvm-svn: 109103
* cache result of operator*Gabor Greif2010-07-121-6/+9
| | | | llvm-svn: 108150
* do not repeatedly dereference use_iteratorGabor Greif2010-07-091-3/+4
| | | | llvm-svn: 107962
* Move FindAvailableLoadedValue isSafeToLoadUnconditionally out ofDan Gohman2010-05-281-0/+1
| | | | | | | lib/Transforms/Utils and into lib/Analysis so that Analysis passes can use them. llvm-svn: 104949
* Teach instcombine to promote alloca array sizes.Dan Gohman2010-05-281-0/+12
| | | | llvm-svn: 104945
* There are two ways of checking for a given type, for example isa<PointerType>(T)Duncan Sands2010-02-161-14/+14
| | | | | | | and T->isPointerTy(). Convert most instances of the first form to the second form. Requested by Chris. llvm-svn: 96344
* Uniformize the names of type predicates: rather than having isFloatTy andDuncan Sands2010-02-151-5/+5
| | | | | | isInteger, we now have isFloatTy and isIntegerTy. Requested by Chris! llvm-svn: 96223
* Check alignment of loads when deciding whether it is safe to execute themBob Wilson2010-01-301-6/+7
| | | | | | | unconditionally. Besides checking the offset, also check that the underlying object is aligned as much as the load itself. llvm-svn: 94875
* Use more specific types to avoid casts. No functionality change.Bob Wilson2010-01-301-6/+6
| | | | llvm-svn: 94863
* Preserve load alignment in instcombine transformations. I've been unable toBob Wilson2010-01-291-0/+3
| | | | | | | | | | create a testcase where this matters. The select+load transformation only occurs when isSafeToLoadUnconditionally is true, and in those situations, instcombine also changes the underlying objects to be aligned. This seems like a good idea regardless, and I've verified that it doesn't pessimize the subsequent realignment. llvm-svn: 94850
* Improve isSafeToLoadUnconditionally to recognize that GEPs with constantBob Wilson2010-01-291-2/+2
| | | | | | | indices are safe if the result is known to be within the bounds of the underlying object. llvm-svn: 94829
* Keep ignoring pointer-to-pointer bitcastsVictor Hernandez2010-01-221-4/+8
| | | | llvm-svn: 94194
* No need to look through bitcasts for DbgInfoIntrinsicVictor Hernandez2010-01-211-13/+6
| | | | llvm-svn: 94112
* Fix comment.Eric Christopher2010-01-191-1/+1
| | | | llvm-svn: 93831
* split out load/store/alloca.Chris Lattner2010-01-051-0/+613
llvm-svn: 92685
OpenPOWER on IntegriCloud