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

[Eli Friedman]

On Mon, Aug 15, 2011 at 5:18 PM, Bill Wendling <wendling at apple.com> wrote:
> 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. :-)

What the code currently does is if there is a landingpad followed by
an unreachable, it will remove the block and change all invokes
referring to it into calls.  From what you're saying, it sounds like
that is correct, but we won't want to do it once we have terminate?

-Eli