[llvm-dev] Question about the order of predecessors in LoopVectorizer with VPlanNatviePath

[jingu kang via llvm-dev]

Hi All,

I have got one domination error after running LoopVectorizer with
VPlanNatviePath.

Let's see simple IR snippet after loop vectorization with VPlanNatviePath.

vector.body:
...
  br label %for.body10.preheader67

for.body10.preheader67:                     ; preds =
%for.cond.cleanup972, %vector.body
  %vec.phi = phi <4 x i64> [ zeroinitializer, %for.cond.cleanup972 ],
[ %8, %vector.body ]
...

for.cond.cleanup972:                              ; preds = %for.body1068
  %8 = add nuw nsw <4 x i64> %vec.phi, <i64 1, i64 1, i64 1, i64 1>
...
  br i1 %10, label %for.cond.cleanup373, label %for.body10.preheader67

As you can see, %vec.phi has wrong incoming basic blocks. It could be as below.

%vec.phi = phi <4 x i64> [ %8, %for.cond.cleanup972 ], [
zeroinitializer, %vector.body ]

The problem comes from "InnerLoopVectorizer::fixNonInductionPHIs()".
This function has assumption about the order of predecessors as below.

    // The predecessor order is preserved and we can rely on mapping between
    // scalar and vector block predecessors.
    for (unsigned i = 0; i < NumIncomingValues; ++i) {

It seems it assumes loop latch as first predecessor and loop preheader
as second one or something like that.

I am not sure there is rule to keep the order of predecessors but I
can see Jump Threading pass generates different order of predecessors
on basic blocks.

If llvm does not have the rule about the order of predecessors, it
seems VPlanNatviePath need to consider the different order of
predecessors. How do you think about it?

Thanks
JinGu Kang