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

[Duncan Sands]

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 aware that SjLj's lowering involves memory accesses, but it's to
> unaliased, private memory.

I agree with this.
>
> I guess it's okay, if a bit weird and unfortunate, to describe landingpad
> as having side-effects in order to get various optimizations to do the
> right thing without custom modification.  But if that's what you're doing,
> you should document it that way.  In the abstract machine, landingpad
> has no side-effects and does not access memory.

As mentioned above, semantically it does access memory.  Otherwise it would
be like a readnone function call, returning the same value every time.  But
it doesn't return the same value every time.  Ergo it reads memory.

Ciao, Duncan.