This is an archive of the discontinued LLVM Phabricator instance.

[mlir][linalg] Tile PadTensorOp
ClosedPublic

Authored by springerm on Jul 5 2021, 11:46 PM.

Details

Summary

Tiling can be enabled with linalg-tile-pad-tensor-ops. Only scf::ForOp can be generated at the moment.

Depends On D105602

Diff Detail

Event Timeline

springerm created this revision.Jul 5 2021, 11:46 PM
springerm requested review of this revision.Jul 5 2021, 11:46 PM
springerm updated this revision to Diff 356616.Jul 6 2021, 12:05 AM

small update

springerm updated this revision to Diff 356683.Jul 6 2021, 4:59 AM

more static types

nicolasvasilache requested changes to this revision.Jul 7 2021, 12:44 PM
nicolasvasilache added inline comments.
mlir/include/mlir/Dialect/Linalg/Passes.td
174 ↗(On Diff #356683)

Can this be folded into the existing tiling pass ?

These are pure mechanics and don't have any policy / heuristics logic anyway.
They are not meant to drive anything other than tests.
Moving them to purely test patterns would also be appropriate.

mlir/include/mlir/Dialect/Linalg/Utils/Utils.h
47 ↗(On Diff #356683)

s/asOpFoldResult/getAsOpFoldResult ?

mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
158

s/writeTileToTensor/insertSliceIntoTensor?

371

The part that performs the tiling rewrite logic should be separated in a standalone transformation.

The pattern should call that transformation, similarly to other similar pattterns.
The part about using filters should be completely separated out and put in the same places as the other patterns that use filters.

The main reason is that these filters are meant to go away in the future when we have something better to control pattern composition.

398

This is a good observation that we have also discussed in other generalization contexts.

Viewing tiling as: given a subset of data, give me the subset of the op that produces the data, generalizes better as rewrite extract_slice(op(x, y, z)) into op(f(x), g(y), h(z)).
Bonus points if in a followup revision you are able to update linalg.generic tiling to operate similarly :) .

539

Can these just be folded in the pass above?

This revision now requires changes to proceed.Jul 7 2021, 12:44 PM
springerm updated this revision to Diff 357117.Jul 7 2021, 7:03 PM
springerm marked an inline comment as done.

rebase

springerm updated this revision to Diff 357145.Jul 7 2021, 11:47 PM
springerm marked 2 inline comments as done.

no change

springerm updated this revision to Diff 357195.Jul 8 2021, 4:51 AM
springerm marked an inline comment as done.

address comments

mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
371

I removed the filter and instead set an attribute manually. This attribute is needed, so that the pattern does not apply infinitely. Basically, this pattern just generates the loop structure. So once the structure is generated, it should not be generated a second time.

What do you mean by "tiling rewrite logic"? Do you mean how to rewrite the PadTensorOp inside the loop? That part is already as minimal as possible. Basically, I just move the PadTensorOp inside the loop nest (by cloning it and replacing the old one with the result of the loop nest). The actual rewrite logic specific to the PadTensorOp is handled by ExtractSliceOfPadTensorSwapPattern.

springerm added inline comments.Jul 8 2021, 4:53 AM
mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
398

Probably requires a larger refactoring, but then it should be possible to use the exact same code path for generating the for-loop for each operation (PadTensorOp and LinalgOp). Looking into this afterwards.

springerm updated this revision to Diff 358190.Jul 13 2021, 1:27 AM

address comments

Moved the tiling functionality into a separate function, as discussed.

Cool thanks for this!

This revision is now accepted and ready to land.Jul 14 2021, 12:09 AM
This revision was landed with ongoing or failed builds.Jul 14 2021, 6:42 PM
This revision was automatically updated to reflect the committed changes.