This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Transform] Add support for dynamically unpacking tile_sizes / num_threads in tile_to_foreach_thread
ClosedPublic

Authored by nicolasvasilache on Nov 12 2022, 12:38 PM.

Details

Summary

This commit adds automatic unpacking of Value's of type pdl::OperationType to the underlying single-result OpResult.
This allows mixing single-value, attribute and multi-value pdl::Operation tile sizes and num threads to TileToForeachThreadOp.

Diff Detail

Event Timeline

nicolasvasilache requested review of this revision.Nov 12 2022, 12:38 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 12 2022, 12:38 PM
nicolasvasilache retitled this revision from [mlir][Transform] Add support for packed tile_sizes / num_threads in tile_to_foreach_thread to [mlir][Transform] Add support for dynamically unpacking tile_sizes / num_threads in tile_to_foreach_thread.
nicolasvasilache edited the summary of this revision. (Show Details)

Update commit message.

springerm accepted this revision.Nov 14 2022, 12:50 AM
springerm added inline comments.
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td
799

to

799–800

I would rephrase this:

`tile_sizes` and `num_threads` are variadic. Each tile size/number of threads can be an index attribute or a transform handle that is mapped to exactly one payload op with exactly one index result.
mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp
1329–1332

Why do you change this? The name of the attr in the .td file is mapping.
If you keep this change, also update the builder decls in the .td file.

1359

May need updating

1394

May need updating

1412

rename variable

1414

No loop needed, because the must be exactly one payload op. Raise an error if a different number of payload ops are mapped.

1436–1437

Nit: If you add this, you skip the error checking inside of unpackPDLOperations which could be useful for debugging faulty IR.

1499–1504

Why is this needed? Is this something that we should do with every transform op?

This revision is now accepted and ready to land.Nov 14 2022, 12:50 AM
nicolasvasilache marked 9 inline comments as done.Nov 14 2022, 4:33 AM
nicolasvasilache added inline comments.
mlir/include/mlir/Dialect/Linalg/TransformOps/LinalgTransformOps.td
799–800

thanks!

mlir/lib/Dialect/Linalg/TransformOps/LinalgTransformOps.cpp
1359

I switched back to mapping everywhere, is that the updating you meant or something else ?

1414

No, that is the whole point of the PR, the handle may point to multiple payload ops that we need to unpack.

[0, %three_tile_sizes, %c42] will unpack to 5 tiles sizes total.

1436–1437

Propagating the empty state properly through the whole transform IR is much more important as it can lead to hard to track issues when used at scale.

If this could be systematized, this would be great but also not on my short-term priority list.

1499–1504

Yes, we should always set the expected handles in the success and silenceable failure cases otherwise hard to track bugs ensue (at the very least in the "Suppress" mode).

A systematic mechanism would be very useful but not on my short term list

nicolasvasilache marked 5 inline comments as done.

Address comments.

This revision was landed with ongoing or failed builds.Nov 14 2022, 4:40 AM
This revision was automatically updated to reflect the committed changes.