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

[John McCall]

On Aug 16, 2011, at 12:04 PM, Bill Wendling wrote:

> 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.

I'm not saying it's exactly like a PHI node, I'm saying it has the same
property of not having a meaningful response to mayReadMemory().

> 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.

This is not an appropriate way of thinking about the instruction.  What
happens during unwinding inheres to the abnormal edge out of a call,
regardless of whether there's a landing pad or whether that landing
pad is actually visited during unwinding.

This is exactly the sort of thing that makes me think that hacking
mayReadMemory() is not the appropriate solution.

> 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.

I'm mostly worried that you're trying to get around doing the actual
correctness work by making general routines inhibit optimization
in all the cases you can think of off the top of your head.

John.