[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