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

[Relax][Bugfix] Apply FuseOps to nested DataflowBlock #17033

Merged

Conversation

Lunderberg
Copy link
Contributor

While it is ill-formed for control-flow to occur within a DataflowBlock, it is legal for a DataflowBlock to be contained within a control-flow. Prior to this commit, the FuseOps and FuseOpsByPattern transforms erroneously skipped DataflowBlock instances that were contained within a relax::If node.

This commit updates FuseOps to apply operator fusion to any dataflow block, regardless of whether it is found at the top level of a a Relax function.

While it is ill-formed for control-flow to occur within a
`DataflowBlock`, it is legal for a `DataflowBlock` to be contained
within a control-flow.  Prior to this commit, the `FuseOps` and
`FuseOpsByPattern` transforms erroneously skipped `DataflowBlock`
instances that were contained within a `relax::If` node.

This commit updates `FuseOps` to apply operator fusion to any dataflow
block, regardless of whether it is found at the top level of a a Relax
function.

Co-authored-by: Chris Sullivan <[email protected]>
@Lunderberg
Copy link
Contributor Author

This PR is identical to the now-closed PR #17022, as a CI restart prevented the CI from running on the original PR.

} else if (leaf_expr->IsInstance<ConstantNode>() || leaf_expr->IsInstance<ShapeExprNode>() ||
leaf_expr->IsInstance<PrimValueNode>() || leaf_expr->IsInstance<StringImmNode>() ||
leaf_expr->IsInstance<DataTypeImmNode>()) {
} else {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@tqchen Responding to the comment here, with conversation migrated to the new PR.

Is this intended change? Seems that we should consider sass where constant value(and there may not be a binding pt)

This change is intentional, and maintains the same behavior for constants as before. Prior to this change, the else if condition was entered for five of the six child classes of relax::LeafExprNode, and the else branch with the LOG(FATAL) was only entered for a relax::Var.

With this change, the behavior of all LeafExpr subclasses is the same: If encoutered without being previously assigned to a group, they are treated as a group of size one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This resolves an issue that results from the use of PostOrderVisit here, in VisitUnsupportedNode. It looks like this function is intended to collect all Var/Constant nodes that are part of the RHS of a binding (e.g. extracting A and B from C = R.add(A,B)). However, it doesn't collect any bindings that may be part of a nested expression. As a result, variable bindings that are part of a conditional's body would erroneously trigger the LOG(FATAL) in VisitLeaf.

@tqchen tqchen merged commit d9240e4 into apache:main May 29, 2024
26 checks passed
@Lunderberg Lunderberg deleted the relax_bugfix_operator_fusion_inside_conditional branch May 29, 2024 14:28
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