llvm dev - May 2009 - [LLVMdev] invoke semantics

On May 22, 2009, at 10:13 AM, Dale Johannesen wrote:
> Should we document it then?  Invokes are confusing enough without
> relying on undocumented behavior:)
It'd be good for someone actually familiar with invoke could comment
on this. Specifically, in the following testcase, the return value of
the invoke is used in the unwind destination, which is not reachable
from the normal destination. Should this be valid?

define i32 @foo() {
entry:
   %t = invoke i32 @bar() to label %normal unwind label %lpad

normal:
   ret i32 0

lpad:
   ret i32 %t
}

declare i32 @bar()


If it's valid, it leads to the following quirky situation:

define i32 @foo() {
entry:
   %t = invoke i32 @bar() to label %normal unwind label %lpad

normal:
   %a = add i32 %t, 1
   ...

lpad:
   %b = add i32 %t, 1
   ...
}

The two adds compute the same value, but it's not possible to
CSE them because there's nowhere to place an instruction that
would be dominated by the operands (the invoke) that would
also dominate all the uses.

Dan

> It'd be good for someone actually familiar with invoke could comment
> on this. Specifically, in the following testcase, the return value of
> the invoke is used in the unwind destination, which is not reachable
> from the normal destination. Should this be valid?
No. If the invoked function unwinds then it doesn't return a value.
I'm pretty sure that -verify will reject your testcase.

Jay.

> Teach IndVarSimplify's FixUsesBeforeDefs to handle InvokeInsts by
> assuming that the use of the value is in a block dominated by the
> "normal" destination.
More precisely, the use has to be dominated by the *edge* from the
invoke to its normal destination. This could certainly do with being
documented properly.

Jay.

On May 22, 2009, at 12:12 PM, Jay Foad wrote:
>> Teach IndVarSimplify's FixUsesBeforeDefs to handle InvokeInsts by
>> assuming that the use of the value is in a block dominated by the
>> "normal" destination.
>
> More precisely, the use has to be dominated by the *edge* from the
> invoke to its normal destination. This could certainly do with being
> documented properly.
Jay is right.  The return value only dominates the normal block, not  
the unwind block.

-Chris

On May 22, 2009, at 12:02 PM, Jay Foad wrote:

>> It'd be good for someone actually familiar with invoke could
comment
>>
>> on this. Specifically, in the following testcase, the return value of
>>
>> the invoke is used in the unwind destination, which is not reachable
>>
>> from the normal destination. Should this be valid?
>>
>
> No. If the invoked function unwinds then it doesn't return a value.
> I'm pretty sure that -verify will reject your testcase.
Thanks to you and others for answering this. I've added a sentence to
LangRef.html making this explicit.

Though, opt -verify does not currently reject the testcase I posted.

Dan