This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Linalg] Refactor transform.structured.pad to separate out hoisting
ClosedPublic

Authored by nicolasvasilache on Feb 27 2023, 1:40 AM.

Diff Detail

Event Timeline

Herald added a reviewer: ftynse. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
nicolasvasilache requested review of this revision.Feb 27 2023, 1:40 AM
springerm added inline comments.Feb 27 2023, 1:57 AM
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td
771–772

Does this also compute an upper bound for tensor dimensions? What happens if the low/high padding and/or tensor source depends on the loop IV?

780

result

791

A loop handle may compose better with the remaining transform dialect ops.

ftynse accepted this revision.Feb 27 2023, 11:38 AM
ftynse added inline comments.
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td
772

Nit: please describe the format of the transform attrbute.

780

I see this text is being copy-pasted, but the logic of apply-to-each doesn't just drop uncompatible ops, it emits a silenceable failure.

781

Nit: it's not a PDLOperation.

793

We don't want overconstrained result types to avoid proliferation of casts, see doc

This revision is now accepted and ready to land.Feb 27 2023, 11:38 AM
nicolasvasilache marked 7 inline comments as done.Feb 28 2023, 12:56 AM
nicolasvasilache added inline comments.
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td
771–772

Does this also compute an upper bound for tensor dimensions?

It does and that has been around for a while; we want to evolve that and merge with your WIP PR that goes towards generalization.
But first, separation of concerns and making room for generalization.

791

Maybe, OTOH getting explicit handles is more cumbersome and makes it harder to e.g. devise tuning scripts.
I could also see us returning the top packing loop and the loop hoisted above for composition, TBD.
Let's keep this as a possible future improvement.

793

thanks!

qcolombet added inline comments.
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
414

Nit: If we don't want to give any special meaning to negative numLoops (e.g., -1 means all of them) maybe we should use unsigned.

Note: I realize that numLoops is used in different APIs with the same type so we can do this clean-up in a separate PR.

qcolombet added inline comments.Feb 28 2023, 1:24 AM
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td
771

Nit: "given number of loops" => "at most the given number of loops"?

We may even want to add wording that the actual number depends on the number of enclosing loops and the given number of loops, whichever is the smallest.

It wasn't clear to me what would happen if we give a number of loops greater than the actual number of enclosing loops. I had to look at the implementation to check.

nicolasvasilache marked 5 inline comments as done.

Address comments and rebase.

mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
414

Moved to int64_t.

I am generally wary of using unsigned to represent non-negative.. unsigned should only be used in very specific limited cases in C++ (e.g. bit manipulation and overflow behavior).
I can dig back the references from some cpp con panel between Stroustrup, Carruth and others if needed, but I prefer to purge unsigned as much as possible.

This revision was landed with ongoing or failed builds.Feb 28 2023, 3:54 AM
This revision was automatically updated to reflect the committed changes.
qcolombet added inline comments.Feb 28 2023, 10:50 AM
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h
414

Yeah, it has some unfortunate codegen implications.

Ideally we would want something that carries the semantic that this number is never negative, while not generating a bunch of codegen/perf overhead.

mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td