[LV] Make LIT test insensitive to basic block numbering

[gilr]

Summary

This patch is part of D28975's breakdown.

induction.ll encodes the specific (and rather arbitrary) numbers given to predicated basic blocks by the unique naming mechanism, which makes it sensitive to changes in LV's instruction generation order. This patch replaces those specific numbers with a numeric pattern.

[mssimpso]

Hi Gil,

While you're working on this, I wonder if you wouldn't mind going further and just making the block names themselves match the regex? Something like:

vector.body:
  %index = phi i32 [ 0, %vector.ph ], [ %index.next, %[[PRED_UDIV_CONTINUE:.+]] ]
  ...
[[PRED_UDIV_CONTINUE]]:
  ...

I've seen this convention in other tests, and it would further harden the test to potential name changes.

[gilr]

Hi Matt,

In D32404#735452, @mssimpso wrote:

I've seen this convention in other tests, and it would further harden the test to potential name changes.

So I was asking myself the same question while doing this. I ended up keeping the hard-coded names since they carry a meaning (similar to vector.body) and can actually make the test more robust while OTOH BB name schemes don't change so often. But we should indeed try to keep it consistent across all LITs one way or the other (interleaved-accesses-pred-stores also seems to hard-code the names). Michael, what do you think?
Since this patch is part of the vplan breakdown I'll commit it as-is (to clarify that the VPlan patch only affects the numbering) and will follow up in a separate patch to unify the behavior across all LITs to what ever pattern we converge to.

[mssimpso]

In D32404#736777, @gilr wrote:

Hi Matt,

In D32404#735452, @mssimpso wrote:

I've seen this convention in other tests, and it would further harden the test to potential name changes.

So I was asking myself the same question while doing this. I ended up keeping the hard-coded names since they carry a meaning (similar to vector.body) and can actually make the test more robust while OTOH BB name schemes don't change so often. But we should indeed try to keep it consistent across all LITs one way or the other (interleaved-accesses-pred-stores also seems to hard-code the names). Michael, what do you think?
Since this patch is part of the vplan breakdown I'll commit it as-is (to clarify that the VPlan patch only affects the numbering) and will follow up in a separate patch to unify the behavior across all LITs to what ever pattern we converge to.

Sounds good to me.

[mkuper]

Honestly, I don't feel strongly about this.

I think the most resilient scheme would be something like matching the meaningful part as a part of the regexp, e.g. [[PRED_UDIV_IF1:pred.udiv.if[0-9]+]], [[PRED_UDIV_IF2:pred.udiv.if[0-9]+]], etc. I'm just not sure the overhead is worth it.

llvm/trunk/test/Transforms/LoopVectorize/induction.ll

 ;   int x = a[i];
 ;   if (c)
 ;     x /= i;
 ;   sum += x;
 ; }
 ;
 ; CHECK-LABEL: @scalarize_induction_variable_05(
 ; CHECK: vector.body:
-; CHECK:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue2 ]
+; CHECK:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue{{[0-9]+}} ]
 ; CHECK:   %[[I0:.+]] = add i32 %index, 0
 ; CHECK:   getelementptr inbounds i32, i32* %a, i32 %[[I0]]
 ; CHECK: pred.udiv.if:
 ; CHECK:   udiv i32 {{.*}}, %[[I0]]
-; CHECK: pred.udiv.if1:
+; CHECK: pred.udiv.if{{[0-9]+}}:
 ; CHECK:   %[[I1:.+]] = add i32 %index, 1
 ; CHECK:   udiv i32 {{.*}}, %[[I1]]
 ;
 ; UNROLL-NO_IC-LABEL: @scalarize_induction_variable_05(
 ; UNROLL-NO-IC: vector.body:
-; UNROLL-NO-IC:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue11 ]
+; UNROLL-NO-IC:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue{{[0-9]+}} ]
 ; UNROLL-NO-IC:   %[[I0:.+]] = add i32 %index, 0
 ; UNROLL-NO-IC:   %[[I2:.+]] = add i32 %index, 2
 ; UNROLL-NO-IC:   getelementptr inbounds i32, i32* %a, i32 %[[I0]]
 ; UNROLL-NO-IC:   getelementptr inbounds i32, i32* %a, i32 %[[I2]]
 ; UNROLL-NO-IC: pred.udiv.if:
 ; UNROLL-NO-IC:   udiv i32 {{.*}}, %[[I0]]
-; UNROLL-NO-IC: pred.udiv.if6:
+; UNROLL-NO-IC: pred.udiv.if{{[0-9]+}}:
 ; UNROLL-NO-IC:   %[[I1:.+]] = add i32 %index, 1
 ; UNROLL-NO-IC:   udiv i32 {{.*}}, %[[I1]]
-; UNROLL-NO-IC: pred.udiv.if8:
+; UNROLL-NO-IC: pred.udiv.if{{[0-9]+}}:
 ; UNROLL-NO-IC:   udiv i32 {{.*}}, %[[I2]]
-; UNROLL-NO-IC: pred.udiv.if10:
+; UNROLL-NO-IC: pred.udiv.if{{[0-9]+}}:
 ; UNROLL-NO-IC:   %[[I3:.+]] = add i32 %index, 3
 ; UNROLL-NO-IC:   udiv i32 {{.*}}, %[[I3]]
 ;
 ; IND-LABEL: @scalarize_induction_variable_05(
 ; IND: vector.body:
-; IND:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue2 ]
+; IND:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue{{[0-9]+}} ]
 ; IND:   %[[E0:.+]] = sext i32 %index to i64
 ; IND:   getelementptr inbounds i32, i32* %a, i64 %[[E0]]
 ; IND: pred.udiv.if:
 ; IND:   udiv i32 {{.*}}, %index
-; IND: pred.udiv.if1:
+; IND: pred.udiv.if{{[0-9]+}}:
 ; IND:   %[[I1:.+]] = or i32 %index, 1
 ; IND:   udiv i32 {{.*}}, %[[I1]]
 ;
 ; UNROLL-LABEL: @scalarize_induction_variable_05(
 ; UNROLL: vector.body:
-; UNROLL:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue11 ]
+; UNROLL:   %index = phi i32 [ 0, %vector.ph ], [ %index.next, %pred.udiv.continue{{[0-9]+}} ]
 ; UNROLL:   %[[I2:.+]] = or i32 %index, 2
 ; UNROLL:   %[[E0:.+]] = sext i32 %index to i64
 ; UNROLL:   %[[G0:.+]] = getelementptr inbounds i32, i32* %a, i64 %[[E0]]
 ; UNROLL:   getelementptr i32, i32* %[[G0]], i64 2
 ; UNROLL: pred.udiv.if:
 ; UNROLL:   udiv i32 {{.*}}, %index
-; UNROLL: pred.udiv.if6:
+; UNROLL: pred.udiv.if{{[0-9]+}}:
 ; UNROLL:   %[[I1:.+]] = or i32 %index, 1
 ; UNROLL:   udiv i32 {{.*}}, %[[I1]]
-; UNROLL: pred.udiv.if8:
+; UNROLL: pred.udiv.if{{[0-9]+}}:
 ; UNROLL:   udiv i32 {{.*}}, %[[I2]]
-; UNROLL: pred.udiv.if10:
+; UNROLL: pred.udiv.if{{[0-9]+}}:
 ; UNROLL:   %[[I3:.+]] = or i32 %index, 3
 ; UNROLL:   udiv i32 {{.*}}, %[[I3]]
 
 define i32 @scalarize_induction_variable_05(i32* %a, i32 %x, i1 %c, i32 %n) {
 entry:
   br label %for.body
 
 for.body: