[llvm-commits] [llvm] r137642 - /llvm/trunk/lib/Transforms/Utils/Local.cpp

[John McCall]

On Aug 16, 2011, at 11:25 AM, Duncan Sands wrote:

> Hi John,
> 
> On 16/08/11 19:32, John McCall wrote:
>> On Aug 15, 2011, at 11:44 PM, Duncan Sands wrote:
>>>> The "landingpad" instruction will never be "trivially" dead.
>>> 
>>> since mayHaveSideEffects() should return true for a landingpad instruction,
>>> this shouldn't be needed: isInstructionTriviallyDead should already return
>>> false.
>> 
>> I don't understand where you and Bill are going with this.  landingpad
>> does not have side-effects, not does it read or write "visible" memory.
> 
> mayReadMemory isn't only about reading visible memory.  The fact that the
> landing pad instruction manages to return (typically) a different exception
> object each time it executes is enough to put it in the mayReadMemory camp.
> That said, I'm not so hot about stating that it writes memory, since
> semantically it doesn't (unlike reading memory).  However it seems more
> convenient to artificially say it writes memory, or has side-effects,
> rather than add special case landing pad logic all over the place to
> get much the same effect.

I'm skeptical that there's really a common abstraction here.  landingpad
instructions, by their nature, must be immune to code motion optimizations.
However, they are never read or write hazards.  What other instruction
behaves this way?  It's closest to a phi.  Does a phi "read memory"?  The
question doesn't really make sense — anyone asking the question
probably just needs to know specifically that it's dealing with a phi.

I understand that some clients will not need special logic if you just
make landingpad claim to have arbitrary side-effects, but that has
costs, too, like decreasing the potential for optimization of any code
with EH in it.  And it's not like you don't have to specifically consider
landingpad instructions for each and every case anyway, because of
the special placement restrictions.

John.