summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms
Commit message (Collapse)AuthorAgeFilesLines
* Enable SCEV-based unrolling by default.Andrew Trick2011-09-021-3/+3
| | | | | | | | | | | | | | | | | | | | This changes loop unrolling to use the same mechanism for trip count computation as indvars. This is a stronger check that tends to unroll more loops. A very common side-effect is that many single iteration loops will be removed sooner. The real goal was simply to remove dependence on canonical IVs. x86 is break even. ARM performance changes to expect (+ is good): External/SPEC/CFP2000/183.equake/183.equake +13% SingleSource/Benchmarks/Dhrystone/fldry +21% MultiSource/Applications/spiff/spiff +3% SingleSource/Benchmarks/Stanford/Puzzle -14% The Puzzle regression is actually an improvement in loop optimization that defeats GVN: rdar://problem/10065079. llvm-svn: 139009
* Compare type size instead of type _store_ size to make sure that BitCastInstJakub Staszak2011-09-021-2/+2
| | | | | | will be valid. This fixes PR10820. llvm-svn: 139005
* Reduce indentation. No functionality change.Bill Wendling2011-09-011-17/+18
| | | | llvm-svn: 138968
* Change worklist driven deletion to be an iterative process.Bill Wendling2011-09-012-42/+12
| | | | | | Duncan noticed this! llvm-svn: 138967
* Fix an issue with the IR sink pass found by inspection. (I'm not sure ↵Eli Friedman2011-09-011-7/+6
| | | | | | anyone is actually using this, but might as well fix it since I found the issue.) llvm-svn: 138965
* Resubmit with fix. Properly remove the instructions except for landingpad, ↵Bill Wendling2011-09-011-9/+28
| | | | | | which should be removed only when its invokes are. llvm-svn: 138932
* Submitted this too early.Bill Wendling2011-09-011-5/+0
| | | | llvm-svn: 138931
* Don't DCE the landingpad instruction.Bill Wendling2011-09-011-0/+5
| | | | | | The landingpad instruction can be removed only when its invokes are removed. llvm-svn: 138930
* Make sure we aren't deleting the landingpad instruction.Bill Wendling2011-08-311-5/+21
| | | | | | | | | The landingpad instruction is required in the landing pad block. Because we're not deleting terminating instructions, the invoke may still jump to here (see Transforms/SCCP/2004-11-16-DeadInvoke.ll). Remove all uses of the landingpad instruction, but keep it around until code-gen can remove the basic block. llvm-svn: 138890
* Remove the old tail duplication pass. It is not used and is unable to updateRafael Espindola2011-08-303-375/+0
| | | | | | | ssa, so it has to be run really early in the pipeline. Any replacement should probably use the SSAUpdater. llvm-svn: 138841
* Speculatively revert r138809 in an attempt to fix DragonEgg.Owen Anderson2011-08-301-2/+1
| | | | llvm-svn: 138829
* When walking backwards to eliminate final stores to allocas at the end of a ↵Owen Anderson2011-08-301-1/+2
| | | | | | function, encountering an unrelated store should not cause us to give up like encountering a load does. llvm-svn: 138809
* Fixes following the CR by Chris and Duncan:Nadav Rotem2011-08-291-5/+0
| | | | | | | Optimize chained bitcasts of the form A->B->A. Undo r138722 and change isEliminableCastPair to allow this case. llvm-svn: 138756
* Bitcasts are transitive. Bitcast-Bitcast-X becomes Bitcast-X.Nadav Rotem2011-08-281-0/+5
| | | | llvm-svn: 138722
* Don't sink landingpad instructions during ind-var simplification.Bill Wendling2011-08-261-0/+4
| | | | llvm-svn: 138651
* Address review comments.Benjamin Kramer2011-08-261-9/+8
| | | | | | | | - Reword comments. - Allow undefined behavior interfering with undefined behavior. - Add address space checks. llvm-svn: 138619
* SimplifyCFG: If we have a PHI node that can evaluate to NULL and do a load ↵Benjamin Kramer2011-08-261-0/+69
| | | | | | | | | | or store to the address returned by the PHI node then we can consider this incoming value as dead and remove the edge pointing there, unless there are instructions that can affect control flow executed in between. In theory this could be extended to other instructions, eg. division by zero, but it's likely that it will "miscompile" some code because people depend on div by zero not trapping. NULL pointer dereference usually leads to a crash so we should be on the safe side. This shrinks the size of a Release clang by 16k on x86_64. llvm-svn: 138618
* LSR wants to split the landing pad's critical edge. Let it do it, but use theBill Wendling2011-08-251-1/+8
| | | | | | proper function to do it. llvm-svn: 138550
* When inserting new instructions, use getFirstInsertionPt instead ofBill Wendling2011-08-256-17/+18
| | | | | | getFirstNonPHI so that it will skip over the landingpad instructions as well. llvm-svn: 138537
* Skip the landingpad instruction when determining the insertion point.Bill Wendling2011-08-241-0/+3
| | | | llvm-svn: 138481
* Use getFirstInsertionPt instead of getFirstNonPHI so that it skips to the properBill Wendling2011-08-241-3/+3
| | | | | | insertion place. llvm-svn: 138473
* Fix a crashing bug in SplitBlock when it is called on a block with noRafael Espindola2011-08-241-5/+6
| | | | | | | | dominator information even though dominators were previously computed. Patch by Nick Sumner. llvm-svn: 138449
* Add a comment.Dan Gohman2011-08-221-0/+4
| | | | llvm-svn: 138243
* Constant pointers to objects don't need reference counting.Dan Gohman2011-08-221-0/+13
| | | | llvm-svn: 138242
* If we're splitting the landing pad block and assigning it only one predecessor,Bill Wendling2011-08-191-26/+40
| | | | | | then don't split it a second time, since that block will be dead. llvm-svn: 138153
* The landingpad instruction isn't dead simply because it's value isn't used.Bill Wendling2011-08-191-1/+1
| | | | llvm-svn: 138102
* Make a bunch of symbols private.Benjamin Kramer2011-08-191-2/+2
| | | | llvm-svn: 138025
* C API functions must be able to see their extern "C" definitions, or it will ↵Benjamin Kramer2011-08-191-0/+1
| | | | | | be impossible to call them from C. llvm-svn: 138022
* Track a retain+release nesting level independently of theDan Gohman2011-08-191-36/+64
| | | | | | | | known-incremented level, because the two concepts can be used to prove the saftey of a retain+release removal in different ways. llvm-svn: 138016
* 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
OpenPOWER on IntegriCloud