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

[Duncan Sands]

Hi Bill, after thinking about this some more I'm starting to agree with John.
It is true that if you invoke a function that throws in a loop, then each
time the landing pad returns a different exception.  But that is because the
called function F is allocating a different exception each time.  Thus F is
not a readonly function :)  However you can imagine a situation in which
exception data has been preallocated, and a readonly function F throws the
same exception each time it is called.  Then the landing pad would return the
same exception each time [*].  In short, it is not the landing pad that is
reading/writing memory, it is the called function.  Indeed the exception
mechanism can be seen as just an alternative way of returning from the function.
Then the landing pad instruction is just like a way of talking about the
returned result, and thus doesn't really do anything (this is vaguely analogous
to a phi node :)), let alone read or write memory.

For example, suppose F can be hoisted out of a loop (eg: because it is readonly
and the loop logic can prove it must execute the same every time).  Then the
landing pad instruction should be hoistable too.  So I'm thinking that stopping
the loop optimizers doing things to landing pad instructions (beyond getting
them to preserve the landing pad invariants) is wrong in general.

Ciao, Duncan.

[*] OK, the unwinder does write stuff into the exception data, but I'm not sure
that matters since semantically this is invisible.

>> 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.
>>
> I disagree. I think it's appropriate to think of this instruction as embodying the events that happen along the abnormal edge. If you consider a regular call, it's used without regard to whether the call may actually return or whether an exception will cause the program to continue at a function up the call stack. The landingpad is analogous.
>
>>> 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, I have thought about this carefully, and this isn't a decision I made without consideration. I appreciate your concern about marking these instructions as reading/writing memory. I simply don't share it. I'm not trying to get around correctness work.
>
> -bw
>