[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