summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Intelligently split the landing pad block.Bill Wendling2011-08-191-5/+16
| | | | | | | | | | We have to be careful when splitting the landing pad block, because the landingpad instruction is required to remain as the first non-PHI of an invoke's unwind edge. To retain this, we split the block into two blocks, moving the predecessors within the loop to one block and the remaining predecessors to the other. The landingpad instruction is cloned into the new blocks. llvm-svn: 138015
* Add SplitLandingPadPredecessors().Bill Wendling2011-08-191-1/+95
| | | | | | | | | | | | | | | | SplitLandingPadPredecessors is similar to SplitBlockPredecessors in that it splits the current block and attaches a set of predecessors to the new basic block. However, it differs from SplitBlockPredecessors in that it's specifically designed to handle landing pad blocks. Two new basic blocks are created: one that is has the vector of predecessors as its predecessors and one that has the remaining predecessors as its predecessors. Those two new blocks then receive a cloned copy of the landingpad instruction from the original block. The landingpad instructions are joined in a PHI, etc. Like SplitBlockPredecessors, it updates the LLVM IR, AliasAnalysis, DominatorTree, DominanceFrontier, LoopInfo, and LCCSA analyses. llvm-svn: 138014
* Use 'getFirstInsertionPt' when trying to insert new instructions during LICM.Bill Wendling2011-08-181-3/+3
| | | | llvm-svn: 138008
* Make it clear that this code is iterating in reverse order through the array.Dan Gohman2011-08-181-2/+3
| | | | llvm-svn: 137985
* Revert r137871. The loop simplify pass should require all exits from a loop thatBill Wendling2011-08-181-15/+3
| | | | | | aren't from an indirect branch need to be dominated by the loop header. llvm-svn: 137981
* Split out the updating of PHI nodes after splitting the BB into a separateBill Wendling2011-08-181-43/+53
| | | | | | function. llvm-svn: 137979
* Use this fantzy ArrayRef thing to pass in the list of predecessors.Bill Wendling2011-08-181-9/+14
| | | | llvm-svn: 137978
* The edge from DISubprogram to DICompileUnit has been removed in recent versionsNick Lewycky2011-08-181-1/+1
| | | | | | of debug info. llvm-svn: 137972
* Use static instead of anonymous namespace.Bill Wendling2011-08-181-7/+4
| | | | llvm-svn: 137959
* Split out the analysis updating code into a helper function. No intendedBill Wendling2011-08-181-63/+78
| | | | | | functionality change. llvm-svn: 137926
* Dramatically speedup codegen prepare by a) avoiding use of dominator tree ↵Devang Patel2011-08-181-16/+38
| | | | | | and b) doing a separate pass over dbg.value instructions. llvm-svn: 137908
* Do not use DebugInfoFinder. Extract debug info directly from llvm.dbg.cu ↵Devang Patel2011-08-171-159/+162
| | | | | | named mdnode. llvm-svn: 137890
* Atomic load/store handling for the passes using memdep (GVN, DSE, memcpyopt).Eli Friedman2011-08-173-9/+11
| | | | llvm-svn: 137888
* Disable PRE for landing pads.Bill Wendling2011-08-171-2/+14
| | | | | | | | PRE needs the landing pads to have their critical edges split. Doing this for a landing pad is non-trivial. Abandon the attempt to perform PRE when we come across a landing pad. (Reviewed by Owen!) llvm-svn: 137876
* Increment the insertion iterator to beyond the landingpad instruction.Bill Wendling2011-08-171-1/+1
| | | | llvm-svn: 137872
* Don't optimize the landing pad exit block.Bill Wendling2011-08-171-4/+18
| | | | | | | | One way to exit the loop is through an unwind edge. However, that may involve splitting the critical edge of the landing pad, which is non-trivial. Prevent the transformation from rewriting the landing pad exit loop block. llvm-svn: 137871
* Assert that we aren't trying to split the critical edge of a landing pad. DoingBill Wendling2011-08-171-0/+5
| | | | | | so requires more care than this generic algorithm should handle. llvm-svn: 137866
* Revert r137655. There is some question about whether the 'landingpad'Bill Wendling2011-08-171-1/+2
| | | | | | instruction should be marked as potentially reading and/or writing memory. llvm-svn: 137863
* Silly mistake from r137777; restore significant isStructTy() checks. While ↵Eli Friedman2011-08-171-4/+19
| | | | | | | | | | here, be a bit more defensive with unknown instructions. Fixes PR10687. llvm-svn: 137836
* A bunch of misc fixes to SCCPSolver::ResolvedUndefsIn, including a fix to stopEli Friedman2011-08-161-40/+72
| | | | | | | | | making random bad assumptions about instructions which are not explicitly listed. Includes fix for rdar://9956541, a version of "undef ^ undef should return 0 because it's easier than arguing with users". llvm-svn: 137777
* Minor bug in SCCP found by inspection. (I don't think it's possible to hit ↵Eli Friedman2011-08-161-0/+7
| | | | | | this with a normal pass pipeline, but fixing for completeness.) llvm-svn: 137755
* Use the getFirstInsertionPt() method instead of getFirstNonPHI + an 'isa<>'Bill Wendling2011-08-164-19/+10
| | | | | | check for a LandingPadInst. llvm-svn: 137745
* I think there was some confusion about what I meant. :-) Replacing the comment.Bill Wendling2011-08-161-1/+4
| | | | llvm-svn: 137743
* Add a mechanism for optimisation plugins to register passes that all front ↵David Chisnall2011-08-161-0/+15
| | | | | | | | ends can use without needing to be aware of the plugin (or the plugin be aware of the front end). Before 3.0, I'd like to add a mechanism for automatically loading a set of plugins from a config file. API suggestions welcome... llvm-svn: 137717
* A few places where we want to skip the landingpad instruction for insertion.Bill Wendling2011-08-162-1/+4
| | | | llvm-svn: 137712
* Revert a bit of r137667; the logic in question can safely handle atomic ↵Eli Friedman2011-08-161-4/+4
| | | | | | load/store. llvm-svn: 137702
* After talking with Bill, it seems like the LandingPad handling here is likelyEli Friedman2011-08-161-4/+1
| | | | | | to be wrong (or at least somewhat suspect). Leave a FIXME for Bill. llvm-svn: 137694
* Minor comment fixes.Eli Friedman2011-08-162-5/+7
| | | | llvm-svn: 137693
* Update SimplifyCFG for atomic operations.Eli Friedman2011-08-151-10/+26
| | | | | | | | This commit includes a mention of the landingpad instruction, but it's not changing the behavior around it. I think the current behavior is correct, though. Bill, can you double-check that? llvm-svn: 137691
* Add comments and test for atomic load/store and mem2reg.Eli Friedman2011-08-151-0/+4
| | | | llvm-svn: 137690
* In places where it's using "getFirstNonPHI", skip the landingpad instruction ↵Bill Wendling2011-08-151-5/+8
| | | | | | if necessary. llvm-svn: 137679
* Don't sink the instruction to before a landingpad instruction.Bill Wendling2011-08-151-1/+1
| | | | llvm-svn: 137672
* Update inter-procedural optimizations for atomic load/store.Eli Friedman2011-08-154-10/+16
| | | | llvm-svn: 137667
* Update instcombine for atomic load/store.Eli Friedman2011-08-153-31/+39
| | | | llvm-svn: 137664
* Duncan pointed out that the LandingPadInst might read memory. (It might alsoBill Wendling2011-08-151-3/+2
| | | | | | write to memory.) Marking it as such makes some checks for immobility go away. llvm-svn: 137655
* Fix llvm::CloneModule to correctly clone globals. Patch per bug report by ↵Eli Friedman2011-08-151-14/+13
| | | | | | Simon Moll on llvmdev. llvm-svn: 137654
* Atomic load/store support in LICM.Eli Friedman2011-08-151-6/+10
| | | | llvm-svn: 137648
* The "landingpad" instruction will never be "trivially" dead.Bill Wendling2011-08-151-0/+4
| | | | llvm-svn: 137642
* Don't try to sink the landingpad instruction. It's immobile.Bill Wendling2011-08-151-2/+3
| | | | llvm-svn: 137629
* Mark the SCC as "might unwind" if we run into a 'resume' instruction.Bill Wendling2011-08-151-2/+3
| | | | llvm-svn: 137627
* Skip the insertion iterator past the landingpad instruction if there.Bill Wendling2011-08-151-0/+1
| | | | llvm-svn: 137626
* Add inlining for the new EH scheme.Bill Wendling2011-08-141-17/+146
| | | | | | | | | | | | | This builds off of the current scheme, but instead of llvm.eh.exception and llvm.eh.selector, it uses the landingpad instruction. And instead of llvm.eh.resume, it uses the resume instruction. Because of the invariants in the landing pad instruction, a lot of code that's currently needed to find the appropriate intrinsic calls for an invoke instruction won't be needed once we go to the new EH scheme. The "FIXME"s tell us what to remove after we switch. llvm-svn: 137576
* This transform is not safe. Thanks to Eli for pointing that out!Nick Lewycky2011-08-141-8/+1
| | | | llvm-svn: 137575
* Don't attempt to add 'nsw' when intermediate instructions had no such guarantee.Nick Lewycky2011-08-141-4/+7
| | | | llvm-svn: 137572
* Teach instcombine to preserve the nsw bit by doing an after-the-fact analysisNick Lewycky2011-08-141-3/+54
| | | | | | when combining add and sub instructions. Patch by Pranav Bhandarkar! llvm-svn: 137570
* Initial commit of the 'landingpad' instruction.Bill Wendling2011-08-121-0/+1
| | | | | | | | | | | | This implements the 'landingpad' instruction. It's used to indicate that a basic block is a landing pad. There are several restrictions on its use (see LangRef.html for more detail). These restrictions allow the exception handling code to gather the information it needs in a much more sane way. This patch has the definition, implementation, C interface, parsing, and bitcode support in it. llvm-svn: 137501
* switch to use the new api for structtypes.Chris Lattner2011-08-122-2/+2
| | | | llvm-svn: 137480
* Silence a bunch (but not all) "variable written but not read" warningsDuncan Sands2011-08-122-1/+3
| | | | | | when building with assertions disabled. llvm-svn: 137460
* Don't convert objc_autoreleaseReturnValue to objc_autorelease if the resultDan Gohman2011-08-121-6/+13
| | | | | | is returned through a bitcast. llvm-svn: 137402
* Don't let arbitrary calls disrupt nested retain+release pairs ifDan Gohman2011-08-121-56/+78
| | | | | | | | | the retains and releases all use the same SSA pointer value. Also, don't let CFG hazards disrupt nested retain+release pair optimizations. llvm-svn: 137399
OpenPOWER on IntegriCloud