diff options
author | Tung D. Le <tung@jp.ibm.com> | 2021-07-30 15:22:21 +0530 |
---|---|---|
committer | Uday Bondhugula <uday@polymagelabs.com> | 2021-07-30 15:22:46 +0530 |
commit | a2186277be1c97ea5c2da890b06cc22b82ffb1a4 (patch) | |
tree | 5df19601217128f0260cc59b1ce664ca0c676f5b /lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp | |
parent | 817f942a287725e758798f5b639e7ca1ccf0e83f (diff) | |
download | llvm-a2186277be1c97ea5c2da890b06cc22b82ffb1a4.zip llvm-a2186277be1c97ea5c2da890b06cc22b82ffb1a4.tar.gz llvm-a2186277be1c97ea5c2da890b06cc22b82ffb1a4.tar.bz2 |
[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
Diffstat (limited to 'lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp')
0 files changed, 0 insertions, 0 deletions