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

[Bill Wendling]

On Aug 17, 2011, at 12:51 PM, Duncan Sands wrote:

> 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.
> 
Well, the functions say *may* read or write memory, not that they necessarily do. :)

> 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.
> 
In this case, once the invoke to F is out of the loop, it's unwind edge will be also, and so will the 'landingpad' instruction.

But let's back up for a second. There's an obvious disparity between what I think of as the semantics of this instruction and what John and you think of as the semantics. As I explained earlier, to me it's meant to embody all of the actions that took place in the "no man's land" between the invoke and it's landing pad. I think of it this way because I want to try to capture in the CFG something which is not easy to capture at all: non-local behavior. Or as you put it an alternative way of returning from the function.

>From what I've been able to gather, you and John are looking at this instruction as *only* an instruction, which happens to be associated with the events that took place on the abnormal edge, but which doesn't embody those actions. Is that a fair assessment?

-bw