[PATCH] D22867: [LV] Untangle the concepts of uniform and scalar

[Wei Mi via llvm-commits]

wmi added a comment.

> Yes, calculuateRegisterUsage uses VecValuesToIgnore. But if we scalarize an induction variable that isn't uniform, we will still create a value for it corresponding to every iteration of the original scalar loop. For example,

> 

>   %index = phi i64 [ 0, %vector.ph ], [ %index.next, %vector.body ]

>   %3 = or i64 %index, 1

>   %4 = or i64 %index, 2

>   %5 = or i64 %index, 3

>   ...

>   %10 = getelementptr inbounds %pair.i16, %pair.i16* %p, i64 %index, i32 1

>   %11 = getelementptr inbounds %pair.i16, %pair.i16* %p, i64 %3, i32 1

>   %12 = getelementptr inbounds %pair.i16, %pair.i16* %p, i64 %4, i32 1

>   %13 = getelementptr inbounds %pair.i16, %pair.i16* %p, i64 %5, i32 1

> 

> 

> Do we not want to consider the ORs in calculateRegisterUsage (or am I misunderstanding the purpose of this function)? Even so, if the GEPs aren't added to VecValuesToIgnore in this case (they're not), why should we add the IV?


There are two factors here:

1. Now calculateRegisterUsage only considers the pressure of vector register, not scalar register. TTI.getNumberOfRegisters only returns vector register number. Scalar register pressure is not modeled in loop vectorization.
2. induction variable has larger impact on register pressure than ORs above, it has live range across the loop while ORs generated have limited live range. If we don't add iv to VecValuesToIgnore, it may involve some impact from scalar register pressure increase into consideration, but it will definitely pessimize the maximum vector register pressure.

I think it is also better to add GEP to VecValuesToIgnore too for non-consecutive memory access case.  although GEP has less impact on vector register pressure than iv.

Thanks,
Wei.


https://reviews.llvm.org/D22867