Conditional Blocks #1666
Merged
Conditional Blocks #1666
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…e end state if not used in inline
…ks when encountering breaks and contiunes
…y ConditionalRegions
tbennun
requested changes
Sep 26, 2024
dace/frontend/python/newast.py
Outdated
| for node, parent in loop_region.all_nodes_recursive(lambda n, _: not isinstance(n, (LoopRegion, SDFGState))): | ||
| if isinstance(node, BreakBlock): | ||
| for in_edge in parent.in_edges(node): | ||
| in_edge.data.assignments["did_break_" + loop_region.label] = "1" |
There was a problem hiding this comment.
I wonder if we should add a __dace_ prefix to avoid name clashes. This is also true in the _generate_orelse code.
There was a problem hiding this comment.
Good point, agree - done.
Comment on lines
+2610
to
+2616
| dead_blocks = [succ for succ in parent.successors(self) if parent.in_degree(succ) == 1] | ||
| while dead_blocks: | ||
| layer = list(dead_blocks) | ||
| dead_blocks.clear() | ||
| for u in layer: | ||
| dead_blocks.extend([succ for succ in parent.successors(u) if parent.in_degree(succ) == 1]) | ||
| parent.remove_node(u) |
There was a problem hiding this comment.
Should this not be part of a transformation / pass like dead state elimination? I am ok with this here now but I still would want a TODO note or TODO(later)
There was a problem hiding this comment.
Good point - I am placing a TODO and will adjust this in the PR that adapts the passes to these changes.
tbennun
approved these changes
Sep 27, 2024
This was referenced Sep 28, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a continuation of #1617 (superseded and closed by this PR), with a lot of the work being done by @luca-patrignani.
Conditional Blocks
This PR implements Conditional Blocks, which are a native way of semantically expressing conditional branching in an SDFG. This replaces the traditional "state machine only" way of expressing conditional branching, with two main goals:
gotostatements for each state transition. However, just as in the above issue, this process is error prone and often leads to invalid code being generated for complex control flow constructs (e.g., conditionals inside of loops with conditional break, continue, return, etc.). By exposing all regular control flow (i.e., loops and conditional branching) with native SDFG constructs, this step can be skipped in code generation.Anatomy of Conditional Blocks
ConditionalBlocks are a type ofControlFlowBlockwhich contains a series of branches. Each branch is represented by a fullControlFlowRegionand has a condition in the form of aCodeBlockattached to it. When aConditionalBlockis executed, the conditions are checked in the insertion order of the branches, and if a matching condition was found, that branch (and only that branch) is executed. When the executed branch finishes executing, theConditionalBlock's successor is next. If no condition matches, no branch is executed.The condition for a single branch at a time may be
None, which represents a wildcard orelsecase that is executed if no conditions match.Code Generation Changes
Code generation (when using this feature) is drastically simplified with respect to control flow: no more control flow detection is performed. Instead, regular control flow constructs are only generated from the new native SDFG constructs (
LoopRegions andConditionalBlocks), and any other state transition is either only used for sequential ordering (unconditional transitions to a single, direct successor), or leads to agoto. This makes code generation significantly less error prone and simpler to work with.Compatibility
This feature is implemented minimally invasive and with full backwards compatibility for now.
Just as with
LoopRegions, this feature is only used if an explicituse_experimental_cfg_blocksflag is set toTruein compatible frontends (currently only Python frontend, Fortran frontend integration is coming soon).If an SDFG makes use of these experimental blocks, some passes and transformations will no longer be applied automatically in pipelines. Transformations that handle these blocks correctly can be explicitly marked with
@transformation.experimental_cfg_block_compatibleto apply them on SDFGs with experimental blocks.Inlining
Conditional blocks can be inlined through a utility function to traditional SDFG state machines. This is automatically done by compatible frontends if the experimental CFG blocks feature is turned off.
Visualization Components
The visualization components are being worked on separately in spcl/dace-webclient#173. This PR does not depend on the visualization components to be merged.