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

[Michael Kruse via llvm-dev]

FWIW, I just ran "ninja check" with the proposed change.
Transforms/LoopVectorize/phi-hang.ll is the only one that fails.

Michael


2016-02-26 18:29 GMT+01:00 Michael Kruse <llvmdev at meinersbur.de>:
> 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
>>
>>