Closed chhzh123 closed 1 year ago
Should throw out an error! Otherwise, it is hard to know where is the problem for large designs.
test_compute_at_with_reuse_2D_complex
is the relevant test case, after compute_at is applied, there will two loops named x and two loops named y, hence the name collision
Fixed this issue by uniquely naming loop axes, this is done by the UniqueName class in context.py in the frontend: cornell-zhang/heterocl@ceab59c44bcfde8ee4e7874a99d4204379098b16
The IR after adding loop unique naming:
#map0 = affine_map<(d0, d1) -> (d0 + d1 * 4)>
#map1 = affine_map<(d0, d1) -> (d0 + d1)>
#map2 = affine_map<(d0, d1, d2) -> (d0 + d1 + d2 * 4)>
module {
func.func @top() -> memref<8x8xi32> attributes {itypes = "", otypes = "s"} {
%0 = memref.alloc() {name = "A"} : memref<10x10xi32>
%1 = memref.alloc() {name = "B"} : memref<8x8xi32>
affine.for %arg0 = 0 to 8 {
affine.for %arg1 = 0 to 2 {
affine.for %arg2 = 0 to 4 {
%3 = affine.apply #map0(%arg2, %arg1)
affine.for %arg3 = 0 to 3 {
%14 = affine.apply #map1(%arg0, %arg3)
affine.for %arg4 = 0 to 3 {
%15 = affine.apply #map2(%arg4, %arg2, %arg1)
%16 = arith.addi %15, %14 {unsigned} : index
%17 = arith.index_cast %16 : index to i32
affine.store %17, %0[%14, %15] {to = "A"} : memref<10x10xi32>
} {loop_name = "x"}
} {loop_name = "y", op_name = "A"}
%4 = affine.load %0[%arg0, %3] {from = "A"} : memref<10x10xi32>
%5 = affine.load %0[%arg0 + 1, %3 + 1] {from = "A"} : memref<10x10xi32>
%6 = arith.extsi %4 : i32 to i33
%7 = arith.extsi %5 : i32 to i33
%8 = arith.addi %6, %7 : i33
%9 = affine.load %0[%arg0 + 2, %3 + 2] {from = "A"} : memref<10x10xi32>
%10 = arith.extsi %8 : i33 to i34
%11 = arith.extsi %9 : i32 to i34
%12 = arith.addi %10, %11 : i34
%13 = arith.trunci %12 : i34 to i32
affine.store %13, %1[%arg0, %3] {to = "B"} : memref<8x8xi32>
} {loop_name = "x_0.inner"}
} {loop_name = "x_0.outer"}
} {loop_name = "y_0", op_name = "B"}
%2 = hcl.create_op_handle "B"
return %1 : memref<8x8xi32>
}
}
Note that the second pair of x and y are automatically named to x_0 and y_0
In this case, there are two
y
and twox
loops here causing the naming collision.B.axis[1]
then refer to the innerx
loop since we directly use the name of theloop_handle
to refer to some loops, so if two loops have the same name, it may cause problems.We need to ensure the loop names are different in the frontend, or use a unique pointer reference pointing to specific loops. (The latter one is probably not workable in MLIR.)