Open rohany opened 1 year ago
@llvm/issue-subscribers-mlir-affine
I attempted to solve this issue, but I don't think I understand the code well enough. I'm leaving what I've found so far here.
I believe the main issue comes when reset the sliceState upper bound. The original value is (d0) -> (d0 + 1)
.
I can't figure out why we need to reset bounds at all. Actually, if I comment out those two lines that I linked above, all the mlir/test/Dialect/Affine
tests still pass anyway. Seems like a case of LoopFusion / Affine code not being mature enough right now.
This issue also occurs when removing mode=sibling
from the mlir-opt
call, that is,
bin/mlir-opt -pass-pipeline='builtin.module(func.func(affine-loop-fusion{fusion-maximal}))'
and I'm not sure what should be the expected behavior here. After a bit of digging, two things seem to go wrong here:
mlir::affine::isLoopMemoryParallel
concludes that both loops are not parallel while they should be. This is caused by the loop in https://github.com/llvm/llvm-project/blob/47cf7a4ba54edf7c2a78503d7cca8a003f194d32/mlir/lib/Dialect/Affine/Analysis/AffineAnalysis.cpp#L172-L174 which checks for dependencies even for operations inside the same loop. So continuing when both are in the same loop ((srcOp->getParentOp() == forOp && dstOp->getParentOp() == forOp)
) could be a possible fix.@dcaballe or @bondhugula could one of you give me some tips? Then I'll probably can get the patch done.
lir::affine::isLoopMemoryParallel concludes that both loops are not parallel while they should be. This is caused by the loop in
Which two loops are you referring to here?
The first loop nest is parallel, but the second isn't parallel (isLoopMemoryParallel considers memory dependences).
The fusion is clearly incorrect here, as you point out -- this is a bug.
Normally, -debug-only=affine-loop-fusion,loop-fusion-utils should give you useful info. In this case, the debug info also looks sparse. I'll fix that to start with.
The following MLIR file:
run with
produces:
This looks incorrect to me, as the reduction into
%arg2[0]
will occur 100 times instead of 10 times now. Withoutfusion-maximal
, the correct fusion gets applied: