summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Utils
Commit message (Collapse)AuthorAgeFilesLines
* Delete trivial landing pads that just continue unwinding the caughtDuncan Sands2011-09-051-0/+49
| | | | | | exception. llvm-svn: 139117
* 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
* When inserting new instructions, use getFirstInsertionPt instead ofBill Wendling2011-08-251-4/+4
| | | | | | getFirstNonPHI so that it will skip over the landingpad instructions as well. llvm-svn: 138537
* 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
* 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
* 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
* 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
* 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
* 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
* I think there was some confusion about what I meant. :-) Replacing the comment.Bill Wendling2011-08-161-1/+4
| | | | llvm-svn: 137743
* 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-161-1/+1
| | | | 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
* 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
* The "landingpad" instruction will never be "trivially" dead.Bill Wendling2011-08-151-0/+4
| | | | llvm-svn: 137642
* 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
* switch to use the new api for structtypes.Chris Lattner2011-08-121-1/+1
| | | | llvm-svn: 137480
* Silence a bunch (but not all) "variable written but not read" warningsDuncan Sands2011-08-121-0/+2
| | | | | | when building with assertions disabled. llvm-svn: 137460
* Distinguish between two copies of one inlined variable. Take 2.Devang Patel2011-08-101-1/+8
| | | | llvm-svn: 137253
* Comments. Thanks for the spell check Nick!Andrew Trick2011-08-102-4/+4
| | | | | | Also, my apologies for spoiling the autocomplete on SimplifyInstructions.cpp. I couldn't think of a better filename. llvm-svn: 137229
* Invoke SimplifyIndVar when we partially unroll a loop. Fixes PR10534.Andrew Trick2011-08-101-1/+24
| | | | llvm-svn: 137203
* Cleanup. Make ScalarEvolution an explicit argument of theAndrew Trick2011-08-101-9/+9
| | | | | | SimplifyIndVar utility since it is required. llvm-svn: 137202
* SimplifyIndVar: make foldIVUser iterative to fold a chain of operands.Andrew Trick2011-08-101-12/+26
| | | | llvm-svn: 137199
* Update CMake build.Benjamin Kramer2011-08-101-0/+1
| | | | llvm-svn: 137198
* Added a SimplifyIndVar utility to simplify induction variable usersAndrew Trick2011-08-101-0/+413
| | | | | | | | | | | | | | | | based on ScalarEvolution without changing the induction variable phis. This utility is the main tool of IndVarSimplifyPass, but the pass also restructures induction variables in strange ways that are sensitive to pass ordering. This provides a way for other loop passes to simplify new uses of induction variables created during transformation. The utility may be used by any pass that preserves ScalarEvolution. Soon LoopUnroll will use it. The net effect in this checkin is to cleanup the IndVarSimplify pass by factoring out the SimplifyIndVar algorithm into a standalone utility. llvm-svn: 137197
* Cleanup. Added LoopBlocksDFS::perform for simple clients.Andrew Trick2011-08-101-7/+2
| | | | llvm-svn: 137195
* Fix the LoopUnroller to handle nontrivial loops and partial unrolling.Andrew Trick2011-08-101-52/+60
| | | | | | | | | | These are not individual bug fixes. I had to rewrite a good chunk of the unroller to make it sane. I think it was getting lucky on trivial completely unrolled loops with no early exits. I included some fairly simple unit tests for partial unrolling. I didn't do much stress testing, so it may not be perfect, but should be usable now. llvm-svn: 137190
* LoopUnroll looks like it has some stale code. Remove it to prove my sanity ↵Andrew Trick2011-08-091-6/+1
| | | | | | and avoid further confusion. llvm-svn: 137106
* There is only one instance of this placeholder being created. Just use thatBill Wendling2011-08-091-6/+6
| | | | | | instead of a vector. llvm-svn: 137099
* Remove an instance where the 'unwind' instruction was created.Bill Wendling2011-08-091-2/+10
| | | | | | | | | The 'unwind' instruction was acting essentially as a placeholder, because it would be replaced at the end of this function by a branch to the "unwind handler". The 'unwind' instruction is going away, so use 'unreachable' instead, which serves the same purpose as a placeholder. llvm-svn: 137098
* Temporarily revert r135528 which distinguishes between two copies of oneChandler Carruth2011-08-051-8/+1
| | | | | | | | | | | | | | | | | | | inlined variable, based on the discussion in PR10542. This explodes the runtime of several passes down the pipeline due to a large number of "copies" remaining live across a large function. This only shows up with both debug and opt, but when it does it creates a many-minute compile when self-hosting LLVM+Clang. There are several other cases that show these types of regressions. All of this is tracked in PR10542, and progress is being made on fixing the issue. Once its addressed, the re-instated, but until then this restores the performance for self-hosting and other opt+debug builds. Devang, let me know if this causes any trouble, or impedes fixing it in any way, and thanks for working on this! llvm-svn: 136953
* We need to map DebugLoc. It leads to Fuction * (through subprogram entry ↵Devang Patel2011-08-041-3/+2
| | | | | | node) which should be appropriately mapped. llvm-svn: 136910
* SCEV: Use AssertingVH to catch dangling BasicBlock* when passes forgetAndrew Trick2011-08-032-2/+17
| | | | | | to notify SCEV of a change. Add forgetLoop in a couple of those places. llvm-svn: 136797
* whitespaceAndrew Trick2011-08-031-7/+7
| | | | llvm-svn: 136795
* Lifetime intrinsics on undef are dead.Nick Lewycky2011-08-021-3/+9
| | | | llvm-svn: 136722
* Revert r136253, r136263, r136269, r136313, r136325, r136326, r136329, r136338,Bill Wendling2011-07-301-142/+19
| | | | | | | r136339, r136341, r136369, r136387, r136392, r136396, r136429, r136430, r136444, r136445, r136446, r136253 pending review. llvm-svn: 136556
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* Some minor cleanups. No functionalitical change.Bill Wendling2011-07-281-17/+10
| | | | llvm-svn: 136341
* Leverage some of the code that John wrote to manage the landing pads.Bill Wendling2011-07-281-32/+56
| | | | | | | The new EH is more simple in many respects. Mainly, we don't have to worry about the "llvm.eh.exception" and "llvm.eh.selector" calls being in weird places. llvm-svn: 136339
* Automatically merge the landingpad clauses when we come across a callee'sBill Wendling2011-07-281-28/+12
| | | | | | landingpad. llvm-svn: 136329
* Initial stab at getting inlining working with the EH rewrite.Bill Wendling2011-07-281-10/+98
| | | | | | | | | This takes the new 'resume' instruction and turns it into a direct jump to the caller's landing pad code. The caller's landingpad instruction is merged with the landingpad instructions of the callee. This is a bit rough and makes some assumptions in how the code works. But it passes a simple test. llvm-svn: 136313
* Refuse to inline two functions which use different personality functions.Bill Wendling2011-07-271-0/+34
| | | | llvm-svn: 136269
OpenPOWER on IntegriCloud