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

[Bill Wendling]

On Aug 16, 2011, at 1:06 PM, John McCall wrote:

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