| Issue |
123291
|
| Summary |
Conversion of Affine Loops to GPU Dialect Fails with 'Invalid Dimension or Symbol Identifier'
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
lhw414
|
## Description
While attempting to convert an affine loop-based MLIR to the GPU dialect using the `convert-affine-for-to-gpu` pass, I encounter the following error:
```plaintext
sample.mlir:8:14: error: 'affine.load' op index must be a valid dimension or symbol identifier
%0 = affine.load %arg0[%arg1, %arg2] : memref<6x12xf32>
^
sample.mlir:8:14: note: see current operation: %8 = "affine.load"(%arg0, %7, %arg13) <{map = affine_map<(d0, d1) -> (d0, d1)>}> : (memref<6x12xf32>, index, index) -> f32
```
The mlir-opt command used to reproduce this issue is:
```bash
../build/bin/mlir-opt sample.mlir -o sample_output.mlir \
-pass-pipeline="builtin.module(func.func(convert-affine-for-to-gpu{gpu-block-dims=1 gpu-thread-dims=0}))"
```
Here is the original input MLIR:
```mlir
module {
memref.global "private" @global_seed : memref<i64> = dense<0>
func.func @main(%arg0: memref<6x12xf32>) -> memref<6x12xf32> {
%cst = arith.constant 0.000000e+00 : f32
%alloc = memref.alloc() {alignment = 64 : i64} : memref<6x12xf32>
affine.for %arg1 = 0 to 6 {
affine.for %arg2 = 0 to 12 {
%0 = affine.load %arg0[%arg1, %arg2] : memref<6x12xf32>
}
}
return %alloc : memref<6x12xf32>
}
}
```
The resulting intermediate IR dump after the failure is as follows:
```mlir
// -----// IR Dump After ConvertAffineForToGPU Failed (convert-affine-for-to-gpu) //-----
"func.func"() <{function_type = (memref<6x12xf32>) -> memref<6x12xf32>, sym_name = "main"}> ({
^bb0(%arg0: memref<6x12xf32>):
%0 = "arith.constant"() <{value = 0.000000e+00 : f32}> : () -> f32
%1 = "memref.alloc"() <{alignment = 64 : i64, operandSegmentSizes = array<i32: 0, 0>}> : () -> memref<6x12xf32>
%2 = "arith.constant"() <{value = 0 : index}> : () -> index
%3 = "arith.constant"() <{value = 6 : index}> : () -> index
%4 = "arith.subi"(%3, %2) <{overflowFlags = #arith.overflow<none>}> : (index, index) -> index
%5 = "arith.constant"() <{value = 1 : index}> : () -> index
%6 = "arith.constant"() <{value = 1 : index}> : () -> index
"gpu.launch"(%4, %6, %6, %6, %6, %6) <{operandSegmentSizes = array<i32: 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0>}> ({
^bb0(%arg1: index, %arg2: index, %arg3: index, %arg4: index, %arg5: index, %arg6: index, %arg7: index, %arg8: index, %arg9: index, %arg10: index, %arg11: index, %arg12: index):
%7 = "arith.addi"(%2, %arg1) <{overflowFlags = #arith.overflow<none>}> : (index, index) -> index
"affine.for"() <{lowerBoundMap = affine_map<() -> (0)>, operandSegmentSizes = array<i32: 0, 0, 0>, step = 1 : index, upperBoundMap = affine_map<() -> (12)>}> ({
^bb0(%arg13: index):
%8 = "affine.load"(%arg0, %7, %arg13) <{map = affine_map<(d0, d1) -> (d0, d1)>}> : (memref<6x12xf32>, index, index) -> f32
"affine.yield"() : () -> ()
}) : () -> ()
"gpu.terminator"() : () -> ()
}) {workgroup_attributions = 0 : i64} : (index, index, index, index, index, index) -> ()
"func.return"(%1) : (memref<6x12xf32>) -> ()
}) : () -> ()
```
## Questions
1. Is there an issue with the original MLIR input?
- Are there any preconditions or required passes that I missed before applying convert-affine-for-to-gpu?
2. Could this be a problem in the convert-affine-for-to-gpu implementation?
- The error suggests that the indices for affine.load are not considered valid dimensions or symbols. However, %arg1 and %arg2 are induction variables of affine.for loops, which are typically valid.
3. What additional passes should be applied before convert-affine-for-to-gpu?
- For instance, should I run canonicalize, lower-affine, or similar passes to simplify the IR and ensure compatibility?
4. Are there any reference backends or examples for converting MLIR with linalg or affine dialects to the GPU dialect?
- I am particularly interested in examples or documentation that describe the process and highlight best practices for such conversions.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
