I was trying to vectorize linalg.conv_2d but I got the following error:
mlir-opt: /stck/moessadk/Workspace/MLIR/new_llvm/llvm-project/mlir/lib/IR/AffineMap.cpp:683: mlir::AffineMap mlir::inverseAndBroadcastProjectedPermuation(mlir::AffineMap): Assertion `map.isProjectedPermutation( true)' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
could you explain please what does mean Projected permuation map? is it a mapping which reduces the rank (for example (i,j)->i) ?
Could you elaborate further how to tile correctly. I try the following options
mlir-opt -test-linalg-codegen-strategy=“anchor-func=compute_rhs3 anchor-op=linalg.conv_2d tile-sizes=1,1 decompose”
to convert to 1-d convolution. I tested other tilings (1,m) and (m,1) before “decompose” but I did not succeed to convert conv_2d to conv_1d.
Convolution differs from matmul in the sense that it has more complicated indexing map for accessing the Input:
You can see in the above there are multiplications and additions among various dimensions and symbols.
While for matmul, we have (i, j, k) -> (i, k) for A, (i, j, k) -> (k, j) for B, and (i, j, k) -> (i, j) for C.
The indexing map for matmul in the above is projected permutations, but not for the convolution Input access.
The way we generate code in MLIR for convolution is trying to decompose it progressively to a reduction like matmul. On observation we have regarding convolution is that if it’s a convolution with filter window sizes all equal to one, then it’s a matmul. So that gives us hints as for how to decompose the problem: driving the window dimensions to ones—
First you’d want to tile the convolution along N, OH, OW, OC to a smaller scale and make sure at least one of OH and OW is one. Then you’d want to tile along KH and KW to make sure at least one of them is one. Then you can use the decompose pattern
to convert the 2-D convolution into a 1-D one and then vectorize.
thank you @antiagainst for your clarification. I am able now to correctly vectorize linalg.conv_2d_nhwc_hwcf but not linalg.conv_2d (convolution version without channels). I looked little bit to the code, it seems that there is no pattern rewrite to down-scale conv_2d op to conv_1d op!!
Yup. Keep in mind that lots of the features in MLIR are developed on concrete needs. We haven’t run into a case where we need the normal linalg.conv_2d thus far. If you need it, please feel free to send patches to wire it up! It shouldn’t be too hard with the fully working example of linalg. conv_2d_nhwc_hwcf. You can reuse the code there to a large extent I think.