[mlir][vector][nfc] Fix typos in tests

[linuxlonelyeagle]

As title,this problem was caused by my negligence.Sorry.

[llvmbot]

@llvm/pr-subscribers-mlir

Author: lonely eagle (linuxlonelyeagle)

Changes

As title,this problem was caused by my negligence.Sorry.

---

Full diff: https://github.com/llvm/llvm-project/pull/126662.diff

1 Files Affected:

• (modified) mlir/test/Conversion/VectorToLLVM/vector-to-llvm-interface.mlir (+20-20)

diff --git a/mlir/test/Conversion/VectorToLLVM/vector-to-llvm-interface.mlir b/mlir/test/Conversion/VectorToLLVM/vector-to-llvm-interface.mlir
index d261327ec005f62..fa7c030538401e9 100644
--- a/mlir/test/Conversion/VectorToLLVM/vector-to-llvm-interface.mlir
+++ b/mlir/test/Conversion/VectorToLLVM/vector-to-llvm-interface.mlir
@@ -530,22 +530,22 @@ func.func @extract_scalar_from_vec_0d_index(%arg0: vector<index>) -> index {
 
 // -----
 
-func.func @extract_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_const(%arg : vector<32x1xi32>) -> i32 {
+func.func @extract_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_const(%arg : vector<32x1xf32>) -> f32 {
   %0 = arith.constant 0 : index
-  %1 = vector.extract %arg[%0, %0] : i32 from vector<32x1xi32>
-  return %1 : i32
+  %1 = vector.extract %arg[%0, %0] : f32 from vector<32x1xf32>
+  return %1 : f32
 }
 
 // At compile time, since the indices of extractOp are constants,
 // they will be collapsed and folded away; therefore, the lowering works.
 
 // CHECK-LABEL: @extract_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_const
-//  CHECK-SAME:   %[[ARG:.*]]: vector<32x1xi32>) -> i32 {
-//       CHECK:   %[[CAST:.*]] = builtin.unrealized_conversion_cast %[[ARG]] : vector<32x1xi32> to !llvm.array<32 x vector<1xi32>>
-//       CHECK:   %[[VEC_0:.*]] = llvm.extractvalue %[[CAST]][0] : !llvm.array<32 x vector<1xi32>>
+//  CHECK-SAME:   %[[ARG:.*]]: vector<32x1xf32>) -> f32 {
+//       CHECK:   %[[CAST:.*]] = builtin.unrealized_conversion_cast %[[ARG]] : vector<32x1xf32> to !llvm.array<32 x vector<1xf32>>
+//       CHECK:   %[[VEC_0:.*]] = llvm.extractvalue %[[CAST]][0] : !llvm.array<32 x vector<1xf32>>
 //       CHECK:   %[[C0:.*]] = llvm.mlir.constant(0 : i64) : i64
-//       CHECK:   %[[RES:.*]] = llvm.extractelement %[[VEC_0]]{{\[}}%[[C0]] : i64] : vector<1xi32>
-//       CHECK:   return %[[RES]] : i32
+//       CHECK:   %[[RES:.*]] = llvm.extractelement %[[VEC_0]]{{\[}}%[[C0]] : i64] : vector<1xf32>
+//       CHECK:   return %[[RES]] : f32
 
 // -----
 
@@ -800,26 +800,26 @@ func.func @insert_scalar_into_vec_2d_f32_dynamic_idx_scalable(%arg0: vector<1x[1
 
 // -----
 
-func.func @insert_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_const(%arg : vector<4x1xi32>) -> vector<4x1xi32> {
+func.func @insert_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_const(%arg : vector<4x1xf32>) -> vector<4x1xf32> {
   %0 = arith.constant 0 : index
-  %1 = arith.constant 1 : i32
-  %res = vector.insert %1, %arg[%0, %0] : i32 into vector<4x1xi32>
-  return %res : vector<4x1xi32>
+  %1 = arith.constant 1.0 : f32
+  %res = vector.insert %1, %arg[%0, %0] : f32 into vector<4x1xf32>
+  return %res : vector<4x1xf32>
 }
 
 // At compile time, since the indices of insertOp are constants,
 // they will be collapsed and folded away; therefore, the lowering works.
 
 // CHECK-LABEL: @insert_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_const
-//  CHECK-SAME:   %[[ARG:.*]]: vector<4x1xi32>) -> vector<4x1xi32> {
-//       CHECK:   %[[CAST:.*]] = builtin.unrealized_conversion_cast %[[ARG]] : vector<4x1xi32> to !llvm.array<4 x vector<1xi32>>
-//       CHECK:   %[[C1:.*]] = arith.constant 1 : i32
-//       CHECK:   %[[VEC_0:.*]] = llvm.extractvalue %[[CAST]][0] : !llvm.array<4 x vector<1xi32>>
+//  CHECK-SAME:   %[[ARG:.*]]: vector<4x1xf32>) -> vector<4x1xf32> {
+//       CHECK:   %[[CAST:.*]] = builtin.unrealized_conversion_cast %[[ARG]] : vector<4x1xf32> to !llvm.array<4 x vector<1xf32>>
+//       CHECK:   %[[C1:.*]] = arith.constant 1.000000e+00 : f32
+//       CHECK:   %[[VEC_0:.*]] = llvm.extractvalue %[[CAST]][0] : !llvm.array<4 x vector<1xf32>>
 //       CHECK:   %[[C0:.*]] = llvm.mlir.constant(0 : i64) : i64
-//       CHECK:   %[[VEC_1:.*]] = llvm.insertelement %[[C1]], %[[VEC_0]]{{\[}}%[[C0]] : i64] : vector<1xi32>
-//       CHECK:   %[[VEC_2:.*]] = llvm.insertvalue %[[VEC_1]], %[[CAST]][0] : !llvm.array<4 x vector<1xi32>>
-//       CHECK:   %[[RES:.*]] = builtin.unrealized_conversion_cast %[[VEC_2]] : !llvm.array<4 x vector<1xi32>> to vector<4x1xi32>
-//       CHECK:   return %[[RES]] : vector<4x1xi32>
+//       CHECK:   %[[VEC_1:.*]] = llvm.insertelement %[[C1]], %[[VEC_0]]{{\[}}%[[C0]] : i64] : vector<1xf32>
+//       CHECK:   %[[VEC_2:.*]] = llvm.insertvalue %[[VEC_1]], %[[CAST]][0] : !llvm.array<4 x vector<1xf32>>
+//       CHECK:   %[[RES:.*]] = builtin.unrealized_conversion_cast %[[VEC_2]] : !llvm.array<4 x vector<1xf32>> to vector<4x1xf32>
+//       CHECK:   return %[[RES]] : vector<4x1xf32>
 
 // -----
 

[banach-space]

Thanks for the fix, LGTM!

Could you try to trim your PR title, please? Please note our coding guidelines:

• https://mlir.llvm.org/getting_started/DeveloperGuide/

That document refers to the following for Git-specific suggestions:

• https://cbea.ms/git-commit/

Note in particular https://cbea.ms/git-commit/#limit-50

50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

In practice, it is hard to stick to 50 chars. However, in your case you can easily rewrite the title as:

[mlir][vector] Fix typos in tests (nfc)

Fix typos in `{insert|extract}_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_constant` - the intention was to use `f32` rather than `i32`.

Hope this helps :)

[linuxlonelyeagle]

Thanks for the fix, LGTM!

Could you try to trim your PR title, please? Please note our coding guidelines:

• https://mlir.llvm.org/getting_started/DeveloperGuide/

That document refers to the following for Git-specific suggestions:

• https://cbea.ms/git-commit/

Note in particular https://cbea.ms/git-commit/#limit-50

50 characters is not a hard limit, just a rule of thumb. Keeping subject lines at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on.

In practice, it is hard to stick to 50 chars. However, in your case you can easily rewrite the title as:

[mlir][vector] Fix typos in tests (nfc)

Fix typos in `{insert|extract}_scalar_from_vec_2d_f32_dynamic_idxs_compile_time_constant` - the intention was to use `f32` rather than `i32`.

Hope this helps :)

Thanks for your guidance. I read the git commit message in the link and learned something new.

[linuxlonelyeagle]

To be honest, I don’t seem to see any guides for modifying the title here https://mlir.llvm.org/getting_started/DeveloperGuide/.I made some changes based on the commit message you provided, and I think this should be fine.Thank you.

[banach-space]

To be honest, I don’t seem to see any guides for modifying the title here https://mlir.llvm.org/getting_started/DeveloperGuide/.I

First:

and then:

made some changes based on the commit message you provided, and I think this should be fine.Thank you.

Thank you, looks great!