[llvm] [LV] Consider whether vscale is a known power of two for iteration check (PR #144963)
David Sherwood via llvm-commits
llvm-commits at lists.llvm.org
Fri Jun 20 08:43:53 PDT 2025
david-arm wrote:
I took an existing test from Transforms/LoopVectorize/AArch64/tail-folding-styles.ll and modified it:
```
define void @simple_memset_tailfold(i32 %val, ptr %ptr, i64 %n) {
entry:
br label %while.body
while.body: ; preds = %while.body, %entry
%index = phi i64 [ %index.next, %while.body ], [ 0, %entry ]
%gep = getelementptr i32, ptr %ptr, i64 %index
%index.next = add nsw i64 %index, 1
%cmp10 = icmp ult i64 %index.next, %n
br i1 %cmp10, label %while.body, label %while.end.loopexit, !llvm.loop !0
while.end.loopexit: ; preds = %while.body
ret void
}
!0 = distinct !{!0, !1, !2, !3, !4}
!1 = !{!"llvm.loop.vectorize.predicate.enable", i1 true}
!2 = !{!"llvm.loop.vectorize.scalable.enable", i1 true}
!3 = !{!"llvm.loop.interleave.count", i32 1}
!4 = !{!"llvm.loop.vectorize.width", i32 4}
```
I then ran opt
```
opt -S -passes=loop-vectorize -force-tail-folding-style=data-and-control -force-target-supports-scalable-vectors < foo.ll
```
and it seems to now hit that code path. It might be a little fragile because there are no memory ops in there and in future I can imagine we might decide there are no vector operations in the loop and abandon vectorisation early on. I think the problem is finding a way to force the target also supporting masked loads and stores.
https://github.com/llvm/llvm-project/pull/144963
More information about the llvm-commits
mailing list