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.
Jay is right. The return value only dominates the normal block, not the unwind block.
-Chris
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
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.
I've had a go at documenting a bit more rigorously how phi and invoke
instructions affect the SSA form. Patch attached.
Though, opt -verify does not currently reject the testcase I posted.
Is it OK to commit my changes to LangRef.html and then raise bugs
against -verify if it doesn't do what I said? 
Thanks,
Jay.
patch.phiinvoke (1.24 KB)
Looks fine. I think -verify got fixed recently to do the right thing here.
-Eli
Is it OK to commit my changes to LangRef.html and then raise bugs
against -verify if it doesn't do what I said?
Please do. I beefed up the verifier, but maybe I missed something.
Ciao,
Duncan.
Is it OK to commit my changes to LangRef.html and then raise bugs
against -verify if it doesn't do what I said?
Please do. I beefed up the verifier, but maybe I missed something.
Looks pretty bomb-proof to me. Thanks for fixing it!
Thanks,
Jay.