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

[John McCall]

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

Bill is incorrect;  terminate should not involve landing pads with
empty, unreachable bodies.  That should only be produceable with
undefined behavior in a cleanup;  as usual, in that case we are
not constrained to deliver any particular behavior.  Erasing the
landing pad seems fine, and you could even mark the call nounwind
if the selector is total.

Whether that optimization is actually worth an enormous drop in
debuggability is a different question.

John.