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

[Bill Wendling]

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 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.
> 
I convinced myself that Duncan was correct with roughly his arguments here. And also that the landingpad is expressing values gotten from an external code path, which obviously reads and writes memory. Marking it thus is not incorrect in that view.

-bw