This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Introduce Transform ops for loops
ClosedPublic

Authored by ftynse on Jun 8 2022, 6:48 AM.

Details

Summary

Introduce transform ops for "for" loops, in particular for peeling, software
pipelining and unrolling, along with a couple of "IR navigation" ops. These ops
are intended to be generalized to different kinds of loops when possible and
therefore use the "loop" prefix. They currently live in the SCF dialect as
there is no clear place to put transform ops that may span across several
dialects, this decision is postponed until the ops actually need to handle
non-SCF loops.

Additionally refactor some common utilities for transform ops into trait or
interface methods, and change the loop pipelining to be a returning pattern.

Diff Detail

Event Timeline

ftynse created this revision.Jun 8 2022, 6:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 8 2022, 6:48 AM
ftynse requested review of this revision.Jun 8 2022, 6:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 8 2022, 6:48 AM
ftynse updated this revision to Diff 435142.Jun 8 2022, 7:03 AM

git add cmake

springerm accepted this revision.Jun 8 2022, 7:37 AM
springerm added inline comments.
mlir/include/mlir/Dialect/SCF/Patterns.h
23

options/options?

26

as the

mlir/include/mlir/Dialect/SCF/TransformOps/SCFTransformOps.td
20

The name of this op suggests that WhileOps would also be taken into account. This op could also work on LoopLikeInterface. Although then it wouldn't really fit into the SCF dialect anymore.

48

a

49

of

50

What does mean? I though the target operand is *the* loop.

69

Peels the last, partial iteration

71

its range

72

iteration

77

Add comment:

Note: If it can be proven statically that the step already evenly divides the range, this op is a no-op. In the absence of sufficient static information, this op may peel a loop, even if the step always divides the range evenly at runtime.
mlir/include/mlir/Dialect/Transform/IR/TransformInterfaces.td
53

operation

mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp
22–28

Can IRRewriter or PatternRewriter be used instead?

132

We may want to return failure() here, indicating that the loop cannot be peeled because the step already divides the range evenly or the step size is 1.

In the long term, maybe a transform dialect op such as try {....} could be useful, which tries to apply a transformation but ignores all failures. (Although that could be dangerous because ops may fail for a variety of reasons.)

Another alternative could be adding an attribute to the LoopPeelOp such as fail_on_already_divisible.

This revision is now accepted and ready to land.Jun 8 2022, 7:37 AM
ftynse added inline comments.Jun 8 2022, 9:04 AM
mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp
22–28

IRRewriter is not a PatternRewriter, and PatternRewriter does not have a public constructor.

ftynse updated this revision to Diff 435234.Jun 8 2022, 10:05 AM
ftynse marked 13 inline comments as done.

Address review

ftynse added inline comments.Jun 8 2022, 10:10 AM
mlir/include/mlir/Dialect/SCF/TransformOps/SCFTransformOps.td
50

Every handle is always associated with the list of operations. Sometimes, the list only has one element, but it is never guaranteed to be the case in general.

69

"partial iteration" doesn't really make sense in loop context.

mlir/lib/Dialect/SCF/TransformOps/SCFTransformOps.cpp
132

In the longer run, we would need some sort of "failible transforms" and a mechanism to propagate error messages from within the transformation code to the caller without emitting them immediately.

This revision was automatically updated to reflect the committed changes.