summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
...
* [IndVars] Fix PR25576Sanjoy Das2016-01-171-23/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `LCSSASafePhiForRAUW` as computed was incorrect -- in cases like these (this exact example does not actually trigger the bug): define i32 @f(i32 %n, i1* %c) { entry: br label %outer.loop outer.loop: br label %inner.loop inner.loop: %iv = phi i32 [ 0, %outer.loop ], [ %iv.inc, %inner.loop ] %iv.inc = add nuw nsw i32 %iv, 1 %tc = udiv i32 %n, 13 %be.cond = icmp ult i32 %iv, %tc br i1 %be.cond, label %inner.loop, label %inner.exit inner.exit: %iv.lcssa = phi i32 [ %iv, %inner.loop ] %outer.be.cond = load volatile i1, i1* %c br i1 %outer.be.cond, label %outer.loop, label %leave leave: %iv.lcssa.lcssa = phi i32 [ %iv.lcssa, %inner.exit ] ret i32 %iv.lcssa.lcssa } `LCSSASafePhiForRAUW` is true for `%iv.lcssa` when re-rewriting the exit value of `%iv` for `%inner.loop` to `%tc` (this can happen due to `SCEVExpander::findExistingExpansion`), but the RAUW breaks LCSSA. To fix this, instead of computing `SafePhi` with special logic, decide the safety of RAUW directly via `replacementPreservesLCSSAForm`. llvm-svn: 258016
* [IndVars] Use emplace_back; NFCSanjoy Das2016-01-171-4/+3
| | | | llvm-svn: 258015
* Fix buildbot failure introduced by 258010. Remove local variables became unused.Artur Pilipenko2016-01-172-7/+0
| | | | llvm-svn: 258011
* Push isDereferenceableAndAlignedPointer down into isSafeToLoadUnconditionallyArtur Pilipenko2016-01-172-16/+6
| | | | | | | | Reviewed By: reames Differential Revision: http://reviews.llvm.org/D16226 llvm-svn: 258010
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-162-2/+2
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* PM: Fix an inverted condition in simplifyFunctionCFGJustin Bogner2016-01-151-2/+1
| | | | | | | | | | | | I mentioned the issue here in code review way back in September and was sure we'd fixed it, but apparently we forgot: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150921/301850.html In any case, as soon as you try to use this pass in anything but the most basic pipeline everything falls apart. Fix the condition. llvm-svn: 257935
* Change isSafeToLoadUnconditionally arguments order. Separated from ↵Artur Pilipenko2016-01-153-10/+10
| | | | | | http://reviews.llvm.org/D10920. llvm-svn: 257894
* [SROA] Also insert a bit piece expression if only one piece is neededKeno Fischer2016-01-141-2/+5
| | | | | | | | | | | | | | Summary: If SROA creates only one piece (e.g. because the other is not needed), it still needs to create a bit_piece expression if that bit piece is smaller than the original size of the alloca. Reviewers: aprantl Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D16187 llvm-svn: 257795
* move return variable declarations down to where they are actually used; NFCISanjay Patel2016-01-131-11/+10
| | | | llvm-svn: 257700
* LoopUnroll: Move the actual unrolling logic to a standalone function. NFCJustin Bogner2016-01-121-86/+95
| | | | | | | This is pure code motion - break the actual work out of runOnLoop into a reusable standalone function. llvm-svn: 257445
* LoopUnroll: Make canUnrollCompletely static - it doesn't use any state. NFCJustin Bogner2016-01-121-11/+5
| | | | llvm-svn: 257427
* LoopUnroll: Clean up the maze of initialization for unroll parameters. NFCJustin Bogner2016-01-121-199/+141
| | | | | | | | | | The layering of where the various loop unroll parameters are initialized and overridden here was very confusing, making it pretty difficult to tell just how the various sources interacted. Instead, we put all of the initialization logic together in a single function so that it's obvious what overrides what. llvm-svn: 257426
* LoopUnroll: Use the optsize threshold for minsize as wellJustin Bogner2016-01-111-4/+1
| | | | | | | | | | | | Currently we're unrolling loops more in minsize than in optsize, which means -Oz will have a larger code size than -Os. That doesn't make any sense. This resolves the FIXME about this in LoopUnrollPass and extends the optsize test to make sure we use the smaller threshold for minsize as well. llvm-svn: 257402
* [JumpThreading] Don't forget to report that the IR changedDavid Majnemer2016-01-101-2/+3
| | | | | | | | | | | | | | JumpThreading's runOnFunction is supposed to return true if it made any changes. JumpThreading has a call to removeUnreachableBlocks which may result in changes to the IR but runOnFunction didn't appropriate account for this possibility, leading to badness. While we are here, make sure to call LazyValueInfo::eraseBlock in removeUnreachableBlocks; JumpThreading preserves LVI. This fixes PR26096. llvm-svn: 257279
* [JumpThreading] Use range-based for loops.Benjamin Kramer2016-01-091-82/+68
| | | | | | No functionality change intended. llvm-svn: 257262
* [TRE] Simplify code with range-based loops and std::find.Benjamin Kramer2016-01-091-7/+2
| | | | | | No functional change intended. llvm-svn: 257261
* [RS4GC] Update and simplify handling of Constants in ↵Manuel Jacob2016-01-091-18/+2
| | | | | | | | | | | | | | | | findBaseDefiningValueOfVector(). Summary: This is analogous to r256079, which removed an overly strong assertion, and r256812, which simplified the code by replacing three conditionals by one. Reviewers: reames Subscribers: sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D16019 llvm-svn: 257250
* [RS4GC] Unify two asserts. NFC.Manuel Jacob2016-01-091-7/+3
| | | | llvm-svn: 257247
* [rs4gc] Optionally directly relocated vector of pointersPhilip Reames2016-01-091-12/+29
| | | | | | | | | | | | | | This patch teaches rewrite-statepoints-for-gc to relocate vector-of-pointers directly rather than trying to split them. This builds on the recent lowering/IR changes to allow vector typed gc.relocates. The motivation for this is that we recently found a bug in the vector splitting code where depending on visit order, a vector might not be relocated at some safepoint. Specifically, the bug is that the splitting code wasn't updating the side tables (live vector) of other safepoints. As a result, a vector which was live at two safepoints might not be updated at one of them. However, if you happened to visit safepoints in post order over the dominator tree, everything worked correctly. Weirdly, it turns out that post order is actually an incredibly common order to visit instructions in in practice. Frustratingly, I have not managed to write a test case which actually hits this. I can only reproduce it in large IR files produced by actual applications. Rather than continue to make this code more complicated, we can remove all of the complexity by just representing the relocation of the entire vector natively in the IR. At the moment, the new functionality is hidden behind a flag. To use this code, you need to pass "-rs4gc-split-vector-values=0". Once I have a chance to stress test with this option and get feedback from other users, my plan is to flip the default and remove the original splitting code. I would just remove it now, but given the rareness of the bug, I figured it was better to leave it in place until the new approach has been stress tested. Differential Revision: http://reviews.llvm.org/D15982 llvm-svn: 257244
* rangify; NFCISanjay Patel2016-01-081-20/+12
| | | | llvm-svn: 257226
* variable names start with an upper case letter; NFCSanjay Patel2016-01-081-7/+7
| | | | llvm-svn: 257213
* [JumpThreading] Split select that has constant conditions coming from the ↵Haicheng Wu2016-01-081-0/+63
| | | | | | | | | | | | | | | | | | | | PHI node Look for PHI/Select in the same BB of the form bb: %p = phi [false, %bb1], [true, %bb2], [false, %bb3], [true, %bb4], ... %s = select p, trueval, falseval And expand the select into a branch structure. This later enables jump-threading over bb in this pass. Using the similar approach of SimplifyCFG::FoldCondBranchOnPHI(), unfold select if the associated PHI has at least one constant. If the unfolded select is not jump-threaded, it will be folded again in the later optimizations. llvm-svn: 257198
* LoopInfo: Simplify ownership of Loop objectsJustin Bogner2016-01-081-1/+1
| | | | | | | | | | | It's strange that LoopInfo mostly owns the Loop objects, but that it defers deleting them to the loop pass manager. Instead, change the oddly named "updateUnloop" to "markAsRemoved" and have it queue the Loop object for deletion. We can't delete the Loop immediately when we remove it, since we need its pointer identity still, so we'll mark the object as "invalid" so that clients can see what's going on. llvm-svn: 257191
* Remove static global GCNames from Function.cpp and move it to the ContextMehdi Amini2016-01-082-2/+2
| | | | | | | | | This remove the need for locking when deleting a function. Differential Revision: http://reviews.llvm.org/D15988 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 257139
* Instructions to be redone only if from the same BBAditya Nandakumar2016-01-071-1/+2
| | | | | | | While adding instructions(possible roots) to be redone, make sure they are from the same basic block. llvm-svn: 257112
* [SCCP] Don't violate the lattice invariantsDavid Majnemer2016-01-071-15/+42
| | | | | | | | | | We marked values which are 'undef' as constant instead of undefined which violates SCCP's invariants. If we can figure out that a computation results in 'undef', leave it in the undefined state. This fixes PR16052. llvm-svn: 257102
* Remove junk accidentally commited with r257087David Majnemer2016-01-071-1/+1
| | | | llvm-svn: 257089
* [SCCP] Can't go from overdefined to constantDavid Majnemer2016-01-071-3/+3
| | | | | | | | The fix for PR23999 made us mark loads of null as producing the constant undef which upsets the lattice. Instead, keep the load as "undefined". This fixes PR26044. llvm-svn: 257087
* [RS4GC] Add an option to suppress vector splittingPhilip Reames2016-01-071-9/+20
| | | | | | At the moment, this is essentially a diangostic option so that I can start collecting failing test cases, but we will eventually migrate to removing the vector splitting code entirely. llvm-svn: 257015
* Fix PR26051: Memcpy optimization should introduce a call to memcpy before ↵Mehdi Amini2016-01-061-2/+4
| | | | | | | | | | the store destination position This is a conservative fix, I expect Amaury to relax this. Follow-up for r256923 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 256999
* Promote aggregate store to memset when possibleAmaury Sechet2016-01-061-1/+27
| | | | | | | | | | | | Summary: As per title. This will allow the optimizer to pick up on it. Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc, joker.eph, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15923 llvm-svn: 256969
* Remove useless DEBUGAmaury Sechet2016-01-061-1/+0
| | | | llvm-svn: 256968
* Improve load/store to memcpy for aggregateAmaury Sechet2016-01-061-9/+23
| | | | | | | | | | | | Summary: It turns out that if we don't try to do it at the store location, we can do it before any operation that alias the load, as long as no operation alias the store. Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc, joker.eph Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15903 llvm-svn: 256923
* Implement load to store => memcpy in MemCpyOpt for aggregatesAmaury Sechet2016-01-051-11/+73
| | | | | | | | | | | | | | | Summary: Most of the tool chain is able to optimize scalar and memcpy like operation effisciently while it isn't that good with aggregates. In order to improve the support of aggregate, we try to change aggregate manipulation into either scalar or memcpy like ones whenever possible without loosing informations. This is one such opportunity. Reviewers: craig.topper, spatel, dexonsmith, Prazek, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15894 llvm-svn: 256868
* [RS4GC] Simplify handling of Constants in findBaseDefiningValue(). NFC.Manuel Jacob2016-01-051-22/+7
| | | | | | | | | | | | | | | Summary: Previously there were three conditionals, checking for global variables, undef values and everything constant except these two, all three returning the same value. This commit replaces them by one conditional. Reviewers: reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15818 llvm-svn: 256812
* [Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.Manuel Jacob2016-01-051-16/+7
| | | | | | | | | | | | | | | Summary: This commit renames GCRelocateOperands to GCRelocateInst and makes it an intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of GCRelocateOperands were changed to use the new intrinsic wrapper instead. Reviewers: sanjoy, reames Subscribers: reames, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15762 llvm-svn: 256811
* [LICM] Fix a small oversight introduced in r256763David Majnemer2016-01-041-6/+6
| | | | | | | | | | | r256763 had promoteLoopAccessesToScalars check for the existence of a catchswitch when the exit blocks were populated but promoteLoopAccessesToScalars may be called with a prepopulated set of exit blocks which would also need to be checked. This fixes PR26019. llvm-svn: 256788
* [LIR] General refactoring to simplify code and the ease future code reviewHaicheng Wu2016-01-041-62/+120
| | | | | | | | | | This is a resubmission of r256336 which was reverted in r256361. The issue was the lack of the invariant check of the memset value in processLooMemSet(). The original message: Move several checks into isLegalStores. Also, delineate between those stores that are memset-able and those that are memcpy-able. llvm-svn: 256783
* Remove dead instructions before RedoingAditya Nandakumar2016-01-041-1/+33
| | | | | | | | | Before reevaluating instructions, iterate over all instructions to be reevaluated and remove trivially dead instructions and if any of it's operands become trivially dead, mark it for deletion until all trivially dead instructions have been removed llvm-svn: 256773
* [LICM] Don't insert instructions after a catchswitch when performing loop ↵David Majnemer2016-01-041-9/+15
| | | | | | | | | promotion Inserting after a catchswitch results in verifier errors, bail out on promotion if a catchswitch is a loop exit. llvm-svn: 256763
* [LICM] Make instruction sinking funclet-awareDavid Majnemer2016-01-041-16/+75
| | | | | | | | | | | We had two bugs here: - We might try to sink into a catchswitch, causing verifier failures. - We will succeed in sinking into a cleanuppad but we didn't update the funclet operand bundle. This fixes PR26000. llvm-svn: 256728
* [RS4GC] Use DenseMap::count() instead of DenseMap::find()/DenseMap::end(). NFC.Manuel Jacob2015-12-291-1/+1
| | | | llvm-svn: 256586
* [PlaceSafepoints] Assert that the gc.safepoint_poll function is present in ↵Manuel Jacob2015-12-291-0/+1
| | | | | | | | | | | the module. If running the PlaceSafepoints pass on a module which doesn't have the gc.safepoint_poll function without disabling entry and backedge safepoints, previously the pass crashed with an obscure error because of a null pointer. Now it fails the assert instead. llvm-svn: 256580
* [JumpThreading] Fix opcode bonus in getJumpThreadDuplicationCost()Geoff Berry2015-12-291-10/+16
| | | | | | | | | | | | The code that was meant to adjust the duplication cost based on the terminator opcode was not being executed in cases where the initial threshold was hit inside the loop. Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D15536 llvm-svn: 256568
* [RS4GC] Fix rematerialization of bitcast of bitcast.Manuel Jacob2015-12-281-6/+2
| | | | | | | | | | | | | | | Summary: Previously, only the outer (last) bitcast was rematerialized, resulting in a use of the unrelocated inner (first) bitcast after the statepoint. See the test case for an example. Reviewers: igor-laevsky, reames Subscribers: reames, alex, llvm-commits, sanjoy Differential Revision: http://reviews.llvm.org/D15789 llvm-svn: 256520
* [gc.statepoint] Change gc.statepoint intrinsic's return type to token type ↵Chen Li2015-12-261-5/+2
| | | | | | | | | | | | | | instead of i32 type Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint. Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob Subscribers: reames, mjacob, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15662 llvm-svn: 256443
* Revert r256336, it caused PR25939Nico Weber2015-12-241-113/+61
| | | | llvm-svn: 256361
* [LIR] General refactoring to simplify code and the ease future code review.Chad Rosier2015-12-231-61/+113
| | | | | | | | | | Move several checks into isLegalStores. Also, delineate between those stores that are memset-able and those that are memcpy-able. http://reviews.llvm.org/D15683 Patch by Haicheng Wu <haicheng@codeaurora.org>! llvm-svn: 256336
* [OperandBundles] Have TailCallElim play nice with operand bundlesDavid Majnemer2015-12-231-2/+2
| | | | | | | | | A call site's use of a Value might not correspond to an argument operand but to a bundle operand. This fixes PR25928. llvm-svn: 256328
* [GC] Make GCStrategy::isGCManagedPointer a type predicate not a value ↵Philip Reames2015-12-231-1/+1
| | | | | | | | | | | predicate [NFC] Reasons: 1) The existing form was a form of false generality. None of the implemented GCStrategies use anything other than a type. Its becoming more and more clear we're going to need some type of strong GC pointer in the type system and we shouldn't pretend otherwise at this point. 2) The API was awkward when applied to vectors-of-pointers. The old one could have been made to work, but calling isGCManagedPointer(Ty->getScalarType()) is much cleaner than the Value alternatives. 3) The rewriting implementation effectively assumes the type based predicate as well. We should be consistent. llvm-svn: 256312
OpenPOWER on IntegriCloud