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

[Bill Wendling]

On Aug 16, 2011, at 11:43 AM, John McCall wrote:
> On Aug 16, 2011, at 11:25 AM, Duncan Sands wrote:
>> 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.
> 

It may be close to a PHI node, but it's not the same. The PHI node has a specific definition and semantics in SSA form. By definition, it doesn't read or write memory. The landingpad instruction is trying to embody all of what happens on the edge between the invoke and the landing pad. Some of those events do read and write memory. We're still allowed to move instructions which may read from or write to memory around, it just requires a bit of extra care. As it is, the instructions which can be moved into the landing pad past the landingpad instruction are rather light-weight instructions which don't read from memory anyway (this is because they're being sunk below an invoke). I'm skeptical that this will adversely affect optimizations for most code.

-bw