[PATCH] D148841: [LV] Use SCEV for uniformity analysis across VF

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 28 12:05:39 PDT 2023


fhahn marked an inline comment as done.
fhahn added a comment.

In D148841#4305388 <https://reviews.llvm.org/D148841#4305388>, @reames wrote:

> Thinking about this a bit, can't the form check be performed in terms of the original IV?  Instead of computing the adjusted IV with the scaled index and an offset, can't we simply reason in terms of the relevant iterations of the original IV?  I think this simply reduces to asking whether OrigIV mod VF is a loop invariant value and the high bits (OrigIV div VF) are fixed between iterations 0 and VF.
>
> Saying that, I the later clause is slightly trickier than 0 and VF.  It's any OrigIV mod VF == 0, and it's correspond OrigIV + VF -1.  (Which is complicated subtraction expression involving the mod.)  Unless maybe it's solving this part which leads to the current solution?

I played around with this a bit before as well before. I might be missing something, but if we have OrigIV as AddRec `{0,+,1}<nuw><nsw><%loop>`, then wouldn't  doing `OrigIV mod VF` always result in an AddRec that cycle through the remainder (for VF = 2, `zext i1 {false,+,true}<%loop> to i64`)? Also, if we would need to identify the AddRec sub-expressions, then we would also need a walk the whole expression as the re-writer does I think.

One other way I could think about reasoning about this would be to evaluate the AddRec at the start and VF-1, but that would only prove it for a specific value.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148841/new/

https://reviews.llvm.org/D148841



More information about the llvm-commits mailing list