[all-commits] [llvm/llvm-project] 2b5d17: [MLIR][Affine-loop-fusion] Fix a bug in affine-loo...

[Tung D. Le via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 2b5d1776ffad2614756ef059d64b957c7731e7be
      https://github.com/llvm/llvm-project/commit/2b5d1776ffad2614756ef059d64b957c7731e7be
  Author: Tung D. Le <tung at jp.ibm.com>
  Date:   2020-06-26 (Fri, 26 Jun 2020)

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

  Log Message:
  -----------
  [MLIR][Affine-loop-fusion] Fix a bug in affine-loop-fusion pass when there are non-affine operations

When there is a mix of affine load/store and non-affine operations (e.g. std.load, std.store),
affine-loop-fusion ignores the present of non-affine ops, thus changing the program semantics.

E.g. we have a program of three affine loops operating on the same memref in which one of them uses std.load and std.store, as follows.
```
affine.for
  affine.store %1
affine.for
  std.load %1
  std.store %1
affine.for
  affine.load %1
  affine.store %1
```
affine-loop-fusion will produce the following result which changed the program semantics:
```
affine.for
  std.load %1
  std.store %1
affine.for
  affine.store %1
  affine.load %1
  affine.store %1
```

This patch is to fix the above problem by checking non-affine users of the memref that are between the source and destination nodes of interest.

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