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

Add if extraction transformation #1641

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

Add if extraction transformation #1641

wants to merge 11 commits into from

Conversation

luigifusco
Copy link
Contributor

As part of the series of SDFG rewriting transformations, IfExtraction targets nested SDFGs that begin with an if statement whose condition is independent of symbols defined or updated in the outer state (these are either writes to arrays or definitions in maps). The if is "extracted": the outers state is duplicated and a new if guard is created in the outer SDFG with the appropriately translated condition. If the edges contain symbol definitions these become definitions in the nested SDFG symbol_mapping.

Example of application:
image
becomes:
image

new_state = outer_sdfg.add_state()
sdutil.change_edge_dest(outer_sdfg, if_branch, new_state)

# take the old state as the if branch, and create a copy to act as the else branch
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 feel like "duplicate_element" should become a utility method of the sdfg

Copy link
Collaborator

Choose a reason for hiding this comment

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

How is this different from a deepcopy?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is already used in some other transformation because according to some comment "it is faster than deepcopy". Consider that deepcopy will copy the entire SDFG as it is referenced in the state. Deepcopying nodes can also lead to invalid state -> deepcopy shoud be used on very small things (edge data, ...) or avoided completely, and some state/node duplication utility should likely be provided in the state/node itself

from dace.properties import make_properties


def eliminate_branch(sdfg: sd.SDFG, initial_state: sd.SDFGState):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Is there an analogous method in the sdfg? Should I make it one?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I do not know of one, if this has potential applicability anywhere else, I would add a good docstring and put it on the ControlFlowRegion or SDFG Utilities.

Copy link
Collaborator

@phschaad phschaad left a comment

Choose a reason for hiding this comment

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

In general happy to accept this, but we need at least one or two unit tests

@acalotoiu
Copy link
Contributor

Agreeing with @phschaad here - tests for when this applies and when it does not apply are needed. Apart from that, it LGTM.

@pratyai pratyai added the no-ci Do not run any CI or actions for this PR label Oct 28, 2024
@pratyai pratyai requested a review from phschaad October 29, 2024 00:11
@pratyai pratyai removed the no-ci Do not run any CI or actions for this PR label Oct 29, 2024
@pratyai
Copy link
Collaborator

pratyai commented Oct 29, 2024

In general happy to accept this, but we need at least one or two unit tests

Added more unit tests, added more explanation. PTAL.

@phschaad
Copy link
Collaborator

Thank you for continuing this @pratyai :-) As with #1639, I would prefer to briefly discuss this in the DaCe meeting before accepting, for the same reasons listed in #1639. However, in general this looks good and I am happy to add this contribution to DaCe.

@phschaad phschaad added question Further information is requested 1.x labels Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.x question Further information is requested
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants