[all-commits] [llvm/llvm-project] a21862: [mlir][affine-loop-fusion] Fix a bug that AffineIf...

[Tung D. Le via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a2186277be1c97ea5c2da890b06cc22b82ffb1a4
      https://github.com/llvm/llvm-project/commit/a2186277be1c97ea5c2da890b06cc22b82ffb1a4
  Author: Tung D. Le <tung at jp.ibm.com>
  Date:   2021-07-30 (Fri, 30 Jul 2021)

  Changed paths:
    M mlir/lib/Transforms/LoopFusion.cpp
    M mlir/test/Transforms/loop-fusion.mlir

  Log Message:
  -----------
  [mlir][affine-loop-fusion] Fix a bug that AffineIfOp prevents fusion of the other loops

The presence of AffineIfOp inside AffineFor prevents fusion of the other loops to happen. For example:

```
  affine.for %i0 = 0 to 10 {
    affine.store %cf7, %a[%i0] : memref<10xf32>
  }
  affine.for %i1 = 0 to 10 {
    %v0 = affine.load %a[%i1] : memref<10xf32>
    affine.store %v0, %b[%i1] : memref<10xf32>
  }
  affine.for %i2 = 0 to 10 {
    affine.if #set(%i2) {
      %v0 = affine.load %b[%i2] : memref<10xf32>
    }
  }
```

The first two loops were not be fused because of `affine.if` inside the last `affine.for`.

The issue seems to come from a conservative constraint that does not allow fusion if there are ops whose number of regions != 0 (affine.if is one of them).

This patch just removes such a constraint when`affine.if` is inside `affine.for`.  The existing `canFuseLoops` method is able to handle `affine.if` correctly.

Reviewed By: bondhugula, vinayaka-polymage

Differential Revision: https://reviews.llvm.org/D105963