Conditional Blocks #173
Merged
Conditional Blocks #173
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
phschaad
changed the title
phschaad
changed the title
github-merge-queue bot
pushed a commit
to spcl/dace
that referenced
this pull request
Sep 27, 2024
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: 1. **Simplify SDFG analysis and optimization by clearly exposing conditional branching.** Previously, detecting and treating conditional branches required expensive analysis of the control flow graph structure, which had to be performed repeatedly and was error prone. By contrast, Conditional Blocks can be generated by a frontend using semantic information from the source language, entirely circumventing this step. 2. **Address code generation issues.** Code generation relies on a series of control flow detections to generate appropriate code that is not full of `goto` statements 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 `ConditionalBlock`s are a type of `ControlFlowBlock` which contains a series of **branches**. Each branch is represented by a full `ControlFlowRegion` and has a condition in the form of a `CodeBlock` attached to it. When a `ConditionalBlock` is 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, the `ConditionalBlock`'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 or `else` case 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 ([`LoopRegion`s](#1475) and `ConditionalBlock`s), and any other state transition is either only used for sequential ordering (unconditional transitions to a single, direct successor), or leads to a `goto`. 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 [`LoopRegion`s](#1475), this feature is only used if an explicit `use_experimental_cfg_blocks` flag is set to `True` in 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_compatible` to 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. --------- Co-authored-by: Luca Patrignani <[email protected]> Co-authored-by: luca-patrignani <[email protected]>
This was referenced Sep 30, 2024
phschaad
force-pushed
the
users/phschaad/conditional_regions
branch
from
fd66c7f to
9260a13
Compare
tbennun
approved these changes
Oct 3, 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 PR introduces the visualization components necessary for the newly introduced Conditional Blocks. For details about conditional blocks, refer to the corresponding PR: spcl/dace#1666.
Conditional blocks show the individual branches side-by-side with the conditions printed above them. An example with 2 nested conditional blocks can be seen below:
Individual branches may be collapsed as shown below:
