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

Control Flow Raising #1657

Merged
merged 25 commits into from
Oct 12, 2024
Merged

Control Flow Raising #1657

merged 25 commits into from
Oct 12, 2024

Conversation

phschaad
Copy link
Collaborator

@phschaad phschaad commented Sep 16, 2024

This PR mainly provides control flow raising passes for the new intrinsic control flow constructs (Branches and loops) in SDFGs. In addition to raising, the state and control flow reachability passes have been adjusted to faithfully work with the intrinsic control flow constructs.

Along with the raising and reachability passes, a few important bugfixes and a general cleanup is included in the PR, but no other functionality is changed.

@phschaad phschaad marked this pull request as draft September 16, 2024 09:56
@phschaad phschaad changed the title Add data dependency analyses Control Flow Raising Oct 7, 2024
@phschaad phschaad marked this pull request as ready for review October 7, 2024 07:43
Copy link
Collaborator

@tbennun tbennun left a comment

Choose a reason for hiding this comment

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

Mostly minor changes, but some serious questions on the tests.

dace/codegen/control_flow.py Show resolved Hide resolved
dace/codegen/targets/framecode.py Outdated Show resolved Hide resolved
dace/sdfg/state.py Outdated Show resolved Hide resolved
dace/sdfg/state.py Show resolved Hide resolved
dace/transformation/interstate/loop_detection.py Outdated Show resolved Hide resolved
itvar, rng, _ = xform.loop_information()
assert itvar == 'i'
assert rng == (0, dace.symbol('N') - 1, 1)
assert sdfg.apply_transformations(xform) == 0
Copy link
Collaborator

Choose a reason for hiding this comment

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

this is very weird because they are loops. We should discuss.
I wonder why this is not detected as a loop because the exiting state (latch->increment1) should have the branch in this case and the latch itself is increment2. This should count as a separate_latch=True case.

Copy link
Collaborator Author

@phschaad phschaad Oct 12, 2024

Choose a reason for hiding this comment

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

I think the easiest solution is just to run state fusion - then that state vanishes anyway and the loop is detected normally.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Still strange, maybe ok. We will see as it directly affects my frontend (my states cannot be fused afaik). Is it because of the graph patterns?

tests/transformations/loop_to_map_test.py Outdated Show resolved Hide resolved
@phschaad phschaad requested a review from tbennun October 12, 2024 13:12
Copy link
Collaborator

@tbennun tbennun left a comment

Choose a reason for hiding this comment

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

LGTM!

@tbennun tbennun added this pull request to the merge queue Oct 12, 2024
Merged via the queue into master with commit 073b613 Oct 12, 2024
10 checks passed
@tbennun tbennun deleted the cf_block_data_deps branch October 12, 2024 21:03
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