affine.for %arg0 = 0 to 300 {
affine.for %arg1 = 0 to 200 {
affine.for %arg2 = 0 to 100 {
The permutation is quite different from what I expected, which is:
affine.for %arg0 = 0 to 200 { // original index 2 goes to 0
affine.for %arg1 = 0 to 300 {// original index 1 goes to 1
affine.for %arg2 = 0 to 100 {// original index 0 goes to 2
I hit the same issue a few weeks ago. I don’t remember the details but I think loop interchange expects the loops to be provided in inner-to-outer order. Otherwise, it won’t do it correctly. You can try:
This clearly looks like a bug and missing / inaccurate documentation as well. Thanks for reporting. mlir::interchangeLoops is also missing assertions on the nesting check as well as on the size of loops. It also does not document what it returns. Could you please file a bug?
On a side note, you don’t need to use makeArrayRef; SmallVector will implicitly convert. Also, SmallVector<unsigned, 3> indexMap = {0, 1, 2}; will work.
For my permutation, the code will only sink by 2 for i==0, which gives exactly the result provided by the code, but not the good permutation.
Formally, the code must decompose the permutation into rotations (sinkLoop), but the code is incorrect because it does not update the loopPermMap while rotations are performed, hence the bug.
I don’t know how to submit a bug. Until now there were the “issues”, but they are now gone…
Hello. The order is correct. Using the order you propose gives an error (exactly because you have to follow an order, something which I did not find in the documentation).