[Mlir-commits] [mlir] [mlir] [Vector] Add IndexBitWidth option to vector-to-llvm pass (PR #128154)

[Rishabh Bali]

================
@@ -0,0 +1,674 @@
+// RUN: mlir-opt %s -convert-vector-to-llvm='index-bitwidth=32' -split-input-file | FileCheck %s
+
+// CHECK-LABEL:   func.func @masked_reduce_add_f32_scalable(
+// CHECK-SAME:                                              %[[VAL_0:.*]]: vector<[16]xf32>,
+// CHECK-SAME:                                              %[[VAL_1:.*]]: vector<[16]xi1>) -> f32 {
+// CHECK:           %[[VAL_2:.*]] = llvm.mlir.constant(0.000000e+00 : f32) : f32
+// CHECK:           %[[VAL_3:.*]] = llvm.mlir.constant(16 : i32) : i32
+// CHECK:           %[[VAL_4:.*]] = "llvm.intr.vscale"() : () -> i32
+// CHECK:           %[[VAL_5:.*]] = builtin.unrealized_conversion_cast %[[VAL_4]] : i32 to index
+// CHECK:           %[[VAL_6:.*]] = arith.index_cast %[[VAL_5]] : index to i32
+// CHECK:           %[[VAL_7:.*]] = arith.muli %[[VAL_3]], %[[VAL_6]] : i32
+// CHECK:           %[[VAL_8:.*]] = "llvm.intr.vp.reduce.fadd"(%[[VAL_2]], %[[VAL_0]], %[[VAL_1]], %[[VAL_7]]) : (f32, vector<[16]xf32>, vector<[16]xi1>, i32) -> f32
+// CHECK:           return %[[VAL_8]] : f32
+// CHECK:         }
+func.func @masked_reduce_add_f32_scalable(%arg0: vector<[16]xf32>, %mask : vector<[16]xi1>) -> f32 {
+  %0 = vector.mask %mask { vector.reduction <add>, %arg0 : vector<[16]xf32> into f32 } : vector<[16]xi1> -> f32
+  return %0 : f32
+}
+
+// -----
+
+// CHECK-LABEL:   func.func @masked_reduce_minf_f32_scalable(
+// CHECK-SAME:                                               %[[VAL_0:.*]]: vector<[16]xf32>,
----------------
quic-rb10 wrote:

Thank you for highlighting this. After further investigation, here are some of my observations:

 
1) I couldn't find any method to infer the bitwidth from the data layout. While such methods do exist, they operate at a much lower level (LLVMIR) than what we are addressing in this PR.

2) LowerToLLVMOptions does have a constructor which takes the datalayout as input, but it doesn't use that data layout to infer the bitwidth.

 `mlir::LowerToLLVMOptions::LowerToLLVMOptions(MLIRContext *ctx,
                                             const DataLayout &dl)
{
  indexBitwidth = dl.getTypeSizeInBits(IndexType::get(ctx));
}`

3) All the tests of the passes at this level like FuncToLLVM, ArithToLLVM, etc directly use the value in indexbitwidth option to override the default bitwidth. Instead of getting the bitwidth from datalayout.

We may need to implement a mechanism to determine the indexbitwidth from the datalayout at the level of toLLVM passes. However, this is beyond the scope of the current patch. This patch aims to add an "indexbitwidth" option to override the default bitwidth, which was previously hardcoded to i64 in many places. The indexType is accessed through the typeconverter, ensuring that the bitwidth is not hardcoded to i64. 

I can push a different patch to add the mechanism to infer the indexbitwidth using the data layout.

https://github.com/llvm/llvm-project/pull/128154