This commit fixes a bug in affine fusion pipeline where an
incorrect fusion is performed despite a dealloc op is present
between a producer and a consumer. This is done by creating a
node for dealloc op in the MDG.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
680 ms | x64 windows > MLIR.Examples/Toy/Ch6::jit.toy | |
4,550 ms | x64 windows > MLIR.Examples/Toy/Ch7::jit.toy |
Event Timeline
Hey Vinayaka!
Thank you so much for the fix! Some comments below.
mlir/lib/Transforms/LoopFusion.cpp | ||
---|---|---|
772 | This looks good to me! I think we have to be more conservative and also add any non-affine operation that produces or uses a memref. Otherwise, hasNonAffineUsersOnThePath won't return the expected output if we have a read, call or alloc-like op or any unknown operation that could potentially make the memref escape, right? | |
mlir/test/Transforms/loop-fusion.mlir | ||
2849 | Would you mind adding also tests with a call op, a load op and an unknown op using the memref, if we don't have it already? Thanks! | |
2860 | I think we should check loads and stores also because we may fuse and do not remove the producer loop. |
https://reviews.llvm.org/D97030 is somehow related. I think the common solution is to represent these missing dependences in the MDG. We may have to coordinate the fixes.
LGTM.
mlir/lib/Transforms/LoopFusion.cpp | ||
---|---|---|
772 | I feel those can be handled in a next patch. This doesn't fix everything but is catching writing and freeing users the right way. | |
mlir/test/Transforms/loop-fusion.mlir | ||
2849 | But this patch isn't meant to fix those. It's only for the users which have a write side-effect or a free side-effect. |
If you could improve the lit test so that loads and stores are also checked, that should be all. Thanks!
mlir/lib/Transforms/LoopFusion.cpp | ||
---|---|---|
772 | Ok, fair enough! |
Suggested additional checks and test-cases submitted at https://reviews.llvm.org/D97252
This looks good to me! I think we have to be more conservative and also add any non-affine operation that produces or uses a memref. Otherwise, hasNonAffineUsersOnThePath won't return the expected output if we have a read, call or alloc-like op or any unknown operation that could potentially make the memref escape, right?