Skip to content
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

[DispatchCreation] Move the logic to transpose indexing maps into dispatch formation logic. #19412

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

MaheshRavishankar
Copy link
Contributor

For cases like

%0 = linalg.matmul
%1 = linalg.generic {
    indexing_maps=[affine_map<(d0, d1) -> (d1, d0)>, ...], ...}
    ins(%0, ... : ...) outs(...) {...}

some preprocessing patterns convert these to

%0 = linalg.matmul
%1 = linalg.generic {
    indexing_maps=[affine_map<(d0, d1) -> (d0, d1)>, ...], ...}
    ins(%0, ... : ...) outs(...) {...}

to make these operations fusable. But these preprocessing are run too
early and doing a spooky-action-at-a-distance.

Instead just move this logic into dispatch formation itself.

Signed-off-by: MaheshRavishankar [email protected]

/// transposed with respect to each other. To find more fusion opportunities for
/// consumer elementwise operation, the indexing maps in the consumer can be
/// made to "align" with the indexing map of the producer to enhance fusion.
static bool areOpsFusableAfterInterchangeOfConsumer(
Copy link
Contributor

@IanWood1 IanWood1 Dec 8, 2024

Choose a reason for hiding this comment

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

Maybe rename this to something like makeConsumerFusableViaInterchange to signal that it modifies the operation? So it's more clear it has side-effects on the indexing maps of the op.

I'm not sure whats going on with the regression tests but otherwise this looks good. I'm glad ElementwiseOpInterchangePattern is getting removed, it was a bit weird and caused some problems

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 on the naming suggestion. It sounds clearer to me.

@MaheshRavishankar MaheshRavishankar force-pushed the handle_transpose_fusion branch 3 times, most recently from caa1290 to 1387b89 Compare December 20, 2024 02:33
@MaheshRavishankar
Copy link
Contributor Author

well, I am going to hold off on submitting anything till the new year.

@MaheshRavishankar MaheshRavishankar force-pushed the handle_transpose_fusion branch 2 times, most recently from ea95ca5 to bef7a87 Compare January 3, 2025 05:33
@ScottTodd ScottTodd removed their request for review January 3, 2025 17:22
@MaheshRavishankar MaheshRavishankar force-pushed the handle_transpose_fusion branch 2 times, most recently from 2e5ce76 to b2e5527 Compare January 13, 2025 00:18
…patch formation logic.

For cases like

```
%0 = linalg.matmul
%1 = linalg.generic {
    indexing_maps=[affine_map<(d0, d1) -> (d1, d0)>, ...], ...}
    ins(%0, ... : ...) outs(...) {...}

```

some preprocessing patterns convert these to

```
%0 = linalg.matmul
%1 = linalg.generic {
    indexing_maps=[affine_map<(d0, d1) -> (d0, d1)>, ...], ...}
    ins(%0, ... : ...) outs(...) {...}

```

to make these operations fusable. But these preprocessing are run too
early and doing a spooky-action-at-a-distance.

Instead just move this logic into dispatch formation itself.

Signed-off-by: MaheshRavishankar <[email protected]>
Signed-off-by: MaheshRavishankar <[email protected]>
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.

5 participants