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

Matthew Simpson via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 29 09:15:08 PDT 2016


mssimpso added a comment.

> > - Moving the induction variable logic out of collectValuesToIgnore. IVs and their updates will now only be placed in VecValuesToIgnore if they're uniform. I believe the existing code was there because the IV scalarization logic needed VecValuesToIgnore to decide if a scalar IV was desired. But now, with a clear distinction between uniform and scalar, think we should move this out. The IVs are handled by isScalarAfterVectorization now.

> 

> 

> Matt, however, not just IV scalarization logic needs VecValuesToIgnore, calculateRegisterUsage to compute vector register pressure also needs it. Because IV's live range always spreads across the whole loop body, and it is often promoted to i64 type, it is important to include IV in VecValuesToIgnore if there is no vector version IV.

> 

> Thanks,

>  Wei.


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?


https://reviews.llvm.org/D22867





More information about the llvm-commits mailing list