This is an archive of the discontinued LLVM Phabricator instance.

[mlir] make `fuse_into_containing_op` preserve the containing op handle
ClosedPublic

Authored by ftynse on May 26 2023, 5:01 AM.

Details

Summary

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.

Diff Detail

Event Timeline

ftynse created this revision.May 26 2023, 5:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 26 2023, 5:01 AM
ftynse requested review of this revision.May 26 2023, 5:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 26 2023, 5:01 AM
springerm accepted this revision.May 26 2023, 5:12 AM
This revision is now accepted and ready to land.May 26 2023, 5:12 AM
nicolasvasilache accepted this revision.May 26 2023, 5:15 AM

thanks for this

ftynse updated this revision to Diff 526042.May 26 2023, 6:18 AM

clang-format