[llvm-dev] Is a PHI use of another PHI in the same block valid?

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 26 09:29:04 PST 2016

If we decide not to be legal, should we change the verify to reject
it? What happens to the test cases that currently test this very
situation (eg. Transforms/LoopVectorize/phi-hang.ll)?

The change as suggested by Philip is:

-  Assert(InstsInThisBlock.count(Op) || DT.dominates(Op, U),
+  Assert((!isa<PHINode>(I) && InstsInThisBlock.count(Op)) ||
+         DT.dominates(Op, U),
+         "Instruction does not dominate all uses!", Op, &I);


2016-02-26 18:02 GMT+01:00 Philip Reames <listmail at philipreames.com>:
> Over in pr26718, we ran across a case where input IR had one PHI within a
> basic block using the value of another PHI within the same basic block
> (without a backedge).  There has been some disagreement as to whether this
> is valid IR.  I believe it is not.
> The verifier currently accepts the following code without error:
> define void @f() {
> entry:
>   br label %next
> next:
>   %y = phi i32 [ 0, %entry ]
>   %x = phi i32 [ %y, %entry ]
>   ret void
> }
> Looking at the code, this may be an oversight - due to a special casing of
> the dominance relation within a single basic block - but that's not
> obviously true.  Thus, we need to clarify what the intended semantics are.
> The lang ref seems pretty clear about this:
> "For the purposes of the SSA form, the use of each incoming value is deemed
> to occur on the edge from the corresponding predecessor block to the current
> block (but after any definition of an ‘invoke‘ instruction’s return value on
> the same edge)."
> But David pointed out that various bits of the optimizer appear to have code
> and test cases covering exactly this case.
> So, is this legal IR?  Or not?
> Philip

More information about the llvm-dev mailing list