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

[Michael Kruse via llvm-dev]

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);

Michael


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