d3e65e702f
Fix a crashing bug in SplitBlock when it is called on a block with no
...
dominator information even though dominators were previously computed.
Patch by Nick Sumner.
llvm-svn: 138449
2011-08-24 18:07:01 +00:00
4b8e8ce37f
Add a comment.
...
llvm-svn: 138243
2011-08-22 17:29:37 +00:00
56e1cef705
Constant pointers to objects don't need reference counting.
...
llvm-svn: 138242
2011-08-22 17:29:11 +00:00
38d813087e
If we're splitting the landing pad block and assigning it only one predecessor,
...
then don't split it a second time, since that block will be dead.
llvm-svn: 138153
2011-08-19 23:46:30 +00:00
26e19288be
The landingpad instruction isn't dead simply because it's value isn't used.
...
llvm-svn: 138102
2011-08-19 21:52:06 +00:00
4938edb02c
Make a bunch of symbols private.
...
llvm-svn: 138025
2011-08-19 01:42:18 +00:00
5a656883b1
C API functions must be able to see their extern "C" definitions, or it will be impossible to call them from C.
...
llvm-svn: 138022
2011-08-19 01:36:54 +00:00
b38940135b
Track a retain+release nesting level independently of the
...
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
2011-08-19 00:26:36 +00:00
c61f7659ba
Intelligently split the landing pad block.
...
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
2011-08-19 00:09:22 +00:00
ca7d309623
Add SplitLandingPadPredecessors().
...
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
2011-08-19 00:05:40 +00:00
2b31c45e8e
Use 'getFirstInsertionPt' when trying to insert new instructions during LICM.
...
llvm-svn: 138008
2011-08-18 23:42:36 +00:00
c57b58cc40
Make it clear that this code is iterating in reverse order through the array.
...
llvm-svn: 137985
2011-08-18 21:27:42 +00:00
b15d6eb93b
Revert r137871. The loop simplify pass should require all exits from a loop that
...
aren't from an indirect branch need to be dominated by the loop header.
llvm-svn: 137981
2011-08-18 21:10:01 +00:00
b267e2a7ec
Split out the updating of PHI nodes after splitting the BB into a separate
...
function.
llvm-svn: 137979
2011-08-18 20:51:04 +00:00
ec3823dcb7
Use this fantzy ArrayRef thing to pass in the list of predecessors.
...
llvm-svn: 137978
2011-08-18 20:39:32 +00:00
74acf9f501
The edge from DISubprogram to DICompileUnit has been removed in recent versions
...
of debug info.
llvm-svn: 137972
2011-08-18 19:07:42 +00:00
6029135af9
Use static instead of anonymous namespace.
...
llvm-svn: 137959
2011-08-18 17:57:57 +00:00
0a693f47ee
Split out the analysis updating code into a helper function. No intended
...
functionality change.
llvm-svn: 137926
2011-08-18 05:25:23 +00:00
53771ba07c
Dramatically speedup codegen prepare by a) avoiding use of dominator tree and b) doing a separate pass over dbg.value instructions.
...
llvm-svn: 137908
2011-08-18 00:50:51 +00:00
2b21d86cfe
Do not use DebugInfoFinder. Extract debug info directly from llvm.dbg.cu named mdnode.
...
llvm-svn: 137890
2011-08-17 22:49:38 +00:00
9a468153e1
Atomic load/store handling for the passes using memdep (GVN, DSE, memcpyopt).
...
llvm-svn: 137888
2011-08-17 22:22:24 +00:00
8bbcbedeaf
Disable PRE for landing pads.
...
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
2011-08-17 21:32:02 +00:00
79a6873d9c
Increment the insertion iterator to beyond the landingpad instruction.
...
llvm-svn: 137872
2011-08-17 21:21:31 +00:00
39257d6b5c
Don't optimize the landing pad exit block.
...
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
2011-08-17 21:20:43 +00:00
2dfbcc4506
Assert that we aren't trying to split the critical edge of a landing pad. Doing
...
so requires more care than this generic algorithm should handle.
llvm-svn: 137866
2011-08-17 21:04:05 +00:00
a9ee09f4be
Revert r137655. There is some question about whether the 'landingpad'
...
instruction should be marked as potentially reading and/or writing memory.
llvm-svn: 137863
2011-08-17 20:36:44 +00:00
d7749be2d7
Silly mistake from r137777; restore significant isStructTy() checks. While here, be a bit more defensive
...
with unknown instructions.
Fixes PR10687.
llvm-svn: 137836
2011-08-17 18:10:43 +00:00
0793eb4c46
A bunch of misc fixes to SCCPSolver::ResolvedUndefsIn, including a fix to stop
...
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
2011-08-16 22:06:31 +00:00
56f2f21254
Minor bug in SCCP found by inspection. (I don't think it's possible to hit this with a normal pass pipeline, but fixing for completeness.)
...
llvm-svn: 137755
2011-08-16 21:12:35 +00:00
8ddfc09e7a
Use the getFirstInsertionPt() method instead of getFirstNonPHI + an 'isa<>'
...
check for a LandingPadInst.
llvm-svn: 137745
2011-08-16 20:45:24 +00:00
55d875fa1c
I think there was some confusion about what I meant. :-) Replacing the comment.
...
llvm-svn: 137743
2011-08-16 20:41:17 +00:00
719a72f34c
Add a mechanism for optimisation plugins to register passes that all front 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
2011-08-16 13:58:41 +00:00
be33e8d58d
A few places where we want to skip the landingpad instruction for insertion.
...
llvm-svn: 137712
2011-08-16 04:52:55 +00:00
a917d4f9b4
Revert a bit of r137667; the logic in question can safely handle atomic load/store.
...
llvm-svn: 137702
2011-08-16 01:28:22 +00:00
bd39703456
After talking with Bill, it seems like the LandingPad handling here is likely
...
to be wrong (or at least somewhat suspect). Leave a FIXME for Bill.
llvm-svn: 137694
2011-08-16 00:41:37 +00:00
b8f30de527
Minor comment fixes.
...
llvm-svn: 137693
2011-08-16 00:20:11 +00:00
0ffdf2ea0b
Update SimplifyCFG for atomic operations.
...
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
2011-08-15 23:59:28 +00:00
01a67111d1
Add comments and test for atomic load/store and mem2reg.
...
llvm-svn: 137690
2011-08-15 23:55:52 +00:00
5a18b7c7c7
In places where it's using "getFirstNonPHI", skip the landingpad instruction if necessary.
...
llvm-svn: 137679
2011-08-15 23:19:54 +00:00
91d4e9edec
Don't sink the instruction to before a landingpad instruction.
...
llvm-svn: 137672
2011-08-15 22:53:05 +00:00
211e348eaa
Update inter-procedural optimizations for atomic load/store.
...
llvm-svn: 137667
2011-08-15 22:16:46 +00:00
8bc586e770
Update instcombine for atomic load/store.
...
llvm-svn: 137664
2011-08-15 22:09:40 +00:00
e86965ee19
Duncan pointed out that the LandingPadInst might read memory. (It might also
...
write to memory.) Marking it as such makes some checks for immobility go away.
llvm-svn: 137655
2011-08-15 21:14:31 +00:00
4d05198d1f
Fix llvm::CloneModule to correctly clone globals. Patch per bug report by Simon Moll on llvmdev.
...
llvm-svn: 137654
2011-08-15 21:05:06 +00:00
91386c7be4
Atomic load/store support in LICM.
...
llvm-svn: 137648
2011-08-15 20:52:09 +00:00
d9fb470758
The "landingpad" instruction will never be "trivially" dead.
...
llvm-svn: 137642
2011-08-15 20:10:51 +00:00
dd94d3426b
Don't try to sink the landingpad instruction. It's immobile.
...
llvm-svn: 137629
2011-08-15 18:23:40 +00:00
88294cdbe0
Mark the SCC as "might unwind" if we run into a 'resume' instruction.
...
llvm-svn: 137627
2011-08-15 18:22:00 +00:00
b9c0e0db53
Skip the insertion iterator past the landingpad instruction if there.
...
llvm-svn: 137626
2011-08-15 18:21:07 +00:00
55421f0c4d
Add inlining for the new EH scheme.
...
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
2011-08-14 08:01:36 +00:00
Rafael Espindola