AffineMin canonicalization hitting an assertion about valid symbol

MLIR
#1

I am working on a change that is related to tiling in Linalg (here). One of the tests seems to be hitting an assertion in folding of affine.min operation. This is the IR

 scf.for %arg3 = %c0 to %c1584 step %c264 {
    scf.for %arg4 = %c0 to %c1584 step %c768 {
      scf.for %arg5 = %c0 to %c1584 step %c768 {
        %0 = affine.min affine_map<(d0) -> (768, -d0 + 1584)>(%arg5)
        %1 = affine.min affine_map<(d0) -> (768, -d0 + 1584)>(%arg4)
        ...
        scf.for %arg6 = %c0 to %4 step %c12 {
          scf.for %arg7 = %c0 to %0 step %c8 {
            scf.for %arg8 = %c0 to %1 step %c16 {
              ...
              %11 = affine.min affine_map<()[s0, s1] -> (16, s1)>()[%c16, %1]

Seems like the folding of %11 = affine.min ... operation checks for if the symbol isValidSymbol which seems to be looking for (amongst other things) that the defining operation is within an AffineScope which seems to be not the case here. I am not fully aware of how to get around this issue. Looking for some advice on this.

@bondhugula, @nicolasvasilache for inputs.

#2

I introduced that but I won’t have the chance to look at it before Aug 31st… I am not sure why you are in an affine scope in your example.

#3

Actually, it shouldn’t be checking for symbol validity. Its only constraint should be that of its operand type being index.

#4

I didnt set it to be AffineScope. So not sure why that is getting involved here, but it seems to be part of the check done here (in promoteComposedSymbolsAsDims). There it is checking if it is a valid symbol. Seems like this is changing all symbols to be dims for better composability of affine.* ops but just dropping this check to be if this is an index type seems to be violating what this method is aiming to do.

#5

Looks like that method is making incorrect assumptions. I didn’t know about that method / didn’t review it.