You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mlir] make fuse_into_containing_op preserve the containing op handle
This partially undoes the intent of https://reviews.llvm.org/D151418 by
cheating its way to keep the "containing op" (aka loop) handle read-only
in fusion. It is crucial to do so for composability of tiling and
fusion. Specfically, after the "containing op" handle started being
consumed, it became impossible to perform additional tiling after fusion
except tiling the last-fused op:
%tiled1, %loop1 = tile %op
%producer1, %loop2 = fuse %producer into %loop1
// invalid, because %tiled1 is invalidated by consuming %loop1
// that points to its parent
tile %tiled1
or
%tiled1, %loop1 = tile %op
%tiled2, %loop2 = tile %tiled1
%p2 = fuse %producer into %loop1
// invalid, because %loop2 is invalidated by consuming %loop1
// that points to its parent
fuse %p2 into %loop2
The approach here makes creative use of the state extension mechanism to
update the payload operation associted with the operand handle. Further
investigation is necessary to understand if is consistent with the
overall execution model of the transform dialect, but it is crucial to
restore composability ASAP.
Reviewed By: springerm, nicolasvasilache
Differential Revision: https://reviews.llvm.org/D151555
0 commit comments