[llvm-commits] [llvm] r137691 - in /llvm/trunk: lib/Transforms/Utils/SimplifyCFG.cpp test/Transforms/SimplifyCFG/trapping-load-unreachable.ll

[Bill Wendling]

On Aug 15, 2011, at 4:59 PM, Eli Friedman wrote:

> Author: efriedma
> Date: Mon Aug 15 18:59:28 2011
> New Revision: 137691
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=137691&view=rev
> Log:
> 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?
> 
Hi Eli,

The changes look okay, but I have a question about this comment:

> +      // Note that deleting LandingPad's here is in fact okay, although it
> +      // involves a bit of subtle reasoning. If this inst is a LandingPad,
> +      // all the predecessors of this block will be the unwind edges of Invokes,
> +      // and we can therefore guaranteed this block will be erased.

I'm not sure what you're trying to get at here. If we have a landing pad instruction followed by an unreachable, that landing pad would be a "terminate" landing pad. I.e., we expect the personality function to call the 'terminate' function. In fact, I initially wanted something like this:

bb1:
  invoke ...
     to label %normal unwind to %unwind

unwind:
  %val = landingpad { i8*, i32 }, personality ...
            terminate
  unreachable

In which case we would not be able to delete the landingpad instruction. I would still like to implement something akin to this, as it's a useful optimization.

My point is that removing landingpad instructions is very tricky, and should be done only if all of the invokes unwinding to the landing pad have been removed or converted into 'call's. :-)

-bw