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

Slight improvement to fusion #86

Merged

Conversation

srinathava
Copy link
Contributor

As discussed, a small improvement to the fusion algorithm to account for the case when we have multiple uses of a definition but all those uses already belong to the group we are in. This allows us to fuse "diamond patterns" of multiple uses into a single group. See the update to the lit test for the improvement.

Note that this still is not a "maximal" fusion which can create groups with multiple returns etc.

Copy link
Collaborator

@navahgar navahgar left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks for updating this.

Couple of minor comments inline.

Comment on lines 40 to 42
// We only support fusing def ops that have exactly one use, for
// now. Special-case the uses of the def in
// tcp.bind_symbolic_shape
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please update this comment to reflect this change.

}
}

if (cannotFuse)
bool canFuse = false;
Copy link
Collaborator

Choose a reason for hiding this comment

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

We have a canFuse above which is a function to check if the def and use can be fused. Can you rename this variable to avoid any confusion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good callout :) fixed.

// 2. All those uses are in the same group as the current op
if (opIsInsideGroup &&
llvm::all_of(otherUses, [&](Operation *userOp) {
return userOp->getParentRegion() == op->getParentRegion();
Copy link
Collaborator

Choose a reason for hiding this comment

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

This works because the op which is the use in this case is already in the group. That is not immediately clear when reading through the code. It is a very subtle. Can you add a comment to explain that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. I had a bit of a longer comment later on. But I repeated it somewhat here just to be additionally clear.

@srinathava srinathava merged commit 7c50225 into cruise-automation:main Jul 29, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants