[Mlir-commits] [mlir] [mlir] Fix mem2reg crash on scalable vector store/load with matching type (PR #209426)
Tobias Gysi
llvmlistbot at llvm.org
Tue Jul 14 06:08:19 PDT 2026
================
@@ -1035,6 +1035,38 @@ llvm.func @scalable_llvm_vector() -> i16 {
// -----
+// Storing into a scalable vector slot with a type matching the slot's
+// element type must not query the type's bit size, as this is not possible
+// for scalable vectors. See #209065.
+
+// CHECK-LABEL: @scalable_vector_matching_store
+llvm.func @scalable_vector_matching_store(%arg: vector<[4]xi1>) {
+ %0 = llvm.mlir.constant(1 : i32) : i32
+ // CHECK-NOT: llvm.alloca
+ %1 = llvm.alloca %0 x vector<[4]xi1> : (i32) -> !llvm.ptr
+ // CHECK-NOT: llvm.store
+ llvm.store %arg, %1 : vector<[4]xi1>, !llvm.ptr
+ llvm.return
+}
+
+// -----
+
+// Loading back a scalable vector value that was stored with a matching type
+// must also avoid querying the type's bit size. See #209065.
----------------
gysit wrote:
```suggestion
```
I think the second test is good enough? Or is there something the first test exercises which is not exercised by the second test?
nit: I would drop the comment. It is completely fine to check the type size and the main purpose of the test is checking the scalable vector promotion which is already reflected by the test name?
https://github.com/llvm/llvm-project/pull/209426
More information about the Mlir-commits
mailing list