Skip to content

[mlir][transform] Consistent linalg transform op syntax for dynamic index lists #90897

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 25 commits into from
May 8, 2024

Conversation

srcarroll
Copy link
Contributor

@srcarroll srcarroll commented May 2, 2024

This patch is a first pass at making consistent syntax across the LinalgTransformOps that use dynamic index lists for size parameters. Previously, there were two different forms: inline types in the list, or place them in the functional style tuple. This patch goes for the latter.

In order to do this, the printPackedOrDynamicIndexList, printDynamicIndexList and their parse counterparts were modified so that the types can be optionally provided to the corresponding custom directives.

All affected ops now use tablegen assemblyFormat, so custom parse/print functions have been removed. There are a couple ops that will likely add dynamic size support, and once that happens it should be made sure that the assembly remains consistent with the changes in this patch.

The affected ops are as follows: pack, pack_greedily, tile_using_forall. The tile_using_for and vectorize ops already used this syntax, but their custom assembly was removed.

Copy link

github-actions bot commented May 4, 2024

✅ With the latest revision this PR passed the Python code formatter.

Copy link

github-actions bot commented May 4, 2024

⚠️ Python code formatter, darker found issues in your code. ⚠️

You can test this locally with the following command:
darker --check --diff -r a4d10266d20bfe5930dfed77e17832af341ed66e...9b7b215e1607fa967c4bfedb749273ace416436c mlir/python/mlir/dialects/transform/structured.py mlir/test/python/dialects/transform_structured_ext.py
View the diff from darker here.
--- test/python/dialects/transform_structured_ext.py	2024-05-03 18:23:17.000000 +0000
+++ test/python/dialects/transform_structured_ext.py	2024-05-03 18:28:25.784985 +0000
@@ -509,11 +509,11 @@
 def testTileToForallPackedDynamic(target):
     n = structured.MatchOp.match_op_names(target, ["test.dummy"])
     structured.TileUsingForallOp(target, num_threads=n)
     # CHECK-LABEL: TEST: testTileToForallPackedDynamic
     # CHECK: = transform.structured.tile_using_forall
-    # CHECK-SAME: num_threads *(%0) : (!transform.any_op, !transform.any_op) 
+    # CHECK-SAME: num_threads *(%0) : (!transform.any_op, !transform.any_op)
 
 
 @run
 @create_sequence
 def testTileToForallMapping(target):

@srcarroll srcarroll changed the title Consistent transform syntax Consistent linalg transform op syntax for dynamic index lists May 4, 2024
@srcarroll srcarroll changed the title Consistent linalg transform op syntax for dynamic index lists [mlir][transform] Consistent linalg transform op syntax for dynamic index lists May 4, 2024
@srcarroll srcarroll marked this pull request as ready for review May 4, 2024 22:48
@srcarroll
Copy link
Contributor Author

I went with my own personal preference. But i'll go with the alternative if insisted.

@@ -1899,7 +1897,17 @@ def TileUsingForOp : Op<Transform_Dialect, "structured.tile_using_for",
$scalableSizes)>,
];

let hasCustomAssemblyFormat = 1;
let assemblyFormat = [{
$target oilist(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for oilist unless there is an actual list inside it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right. my bad. learned that in the last PR and didn't pay attention here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm. so actually oilist seems to still serve two purposes here. One is that it makes the vector_sizes keyword optional. Second is that it will elide vector_sizes when the list is empty. If I change to something like

  let assemblyFormat = [{
    $target
      (`vector_sizes` custom<DynamicIndexList>(
        $vector_sizes,
        $static_vector_sizes,
        $scalable_sizes)^)?
    attr-dict
    `:` type($target)(`,`type($vector_sizes)^)? 
  }];

then this still handles the first thing, but not the second. any suggestions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I leave as is there another way without it that will keep the current behavior?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I also get to learn something ;). Feel free to keep it and add a comment as this is non-obvious (oilist stands for order-independent list so unclear why it would be used for something that isn't a list).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will do

@@ -2162,7 +2166,16 @@ def VectorizeOp : Op<Transform_Dialect, "structured.vectorize",

let results = (outs);

let hasCustomAssemblyFormat = 1;
let assemblyFormat = [{
$target oilist(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i did remove for this as i believe the intention is that tile_sizes is never optional, nor does it make sense to allow empty list

@srcarroll srcarroll merged commit 2c1c676 into llvm:main May 8, 2024
@srcarroll srcarroll deleted the consistent-transform-syntax branch June 5, 2024 02:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants