Conversation
|
|
||
| ### Step 1. Input Ordering | ||
|
|
||
| The inputs from `bb0`, `bb1`, and `bb2` (namely `%c0_i32`, `%c0_i32_0`, and `%9`) are referred to as **x₀**, **x₁**, and **x₂**, respectively. |
There was a problem hiding this comment.
Worth mentioning that you are referring to the first ϕ which is the first argument in bb3.
| - **x₁:** `{bb0, bb1, bb3}` *(must not pass through `bb2`, the later operand producer)* | ||
| - **x₂:** `{bb0, bb1, bb2, bb3}` | ||
|
|
||
| Next, we filter paths by the **sender block** (the block immediately before the ϕ) to ensure correct operand assignment: |
There was a problem hiding this comment.
(the block immediately before the ϕ) can be more precise as follows: (the block immediately before the block of the ϕ in a path from the common dominator to the block of the ϕ).
|
|
||
| Next, we filter paths by the **sender block** (the block immediately before the ϕ) to ensure correct operand assignment: | ||
|
|
||
| - `%c0_i32` (x₀) sender: `bb0` → path `{bb0, bb3}` |
There was a problem hiding this comment.
Cosmetic but having an → suggests that bb0 implies or results in the path. Maybe replace it with bb0 because the path is {bb0, bb3}?
Also, for consistency with the above either have %c0_i32 (x₀) or **x₀:** in both.
| 3. Convert remaining ϕ gates into γ gates. | ||
|
|
||
| ## Identify Implicit ϕ Gates | ||
| In the `convertSSAToGSA` function, the first step is to convert all block arguments in the IR into ϕ gates, carefully extracting information about their producers and senders. Later, these ϕ gates are transformed into either γ or μ gates. |
There was a problem hiding this comment.
Before diving into the functions and the data structures, we need to mention the existence of the GSA experimental Analysis pass and possibly add a link https://github.com/EPFL-LAP/dynamatic/blob/main/experimental/lib/Analysis/GSAAnalysis.cpp to it.
|
|
||
| #### Gate Structure | ||
|
|
||
| A **Gate** represents a logical or control flow construct in the GSA form. Each gate encapsulates: |
There was a problem hiding this comment.
A bit ambiguous: what exactly does logical or control flow construct mean? Isn't it simply a representative of a GSA gate or an SSA ϕ?
|
|
||
| - And a unique identity within the region. | ||
|
|
||
| Below is a simplified version of the Gate structure used in the implementation: |
There was a problem hiding this comment.
Why is it simplified? What did you omit?
|
|
||
| - For γ gates, it is the producer block of the condition that determines which input the γ selects. | ||
|
|
||
| - For μ gates, it refers to the producer of the unique loop exit condition (the condition that decides when the loop terminates). |
There was a problem hiding this comment.
I would explicitly say it here that if the loop containing the μ gate at its header has a single unique loop exit, then this field refers to this unique loop exit block.
|
|
||
| - For μ gates, it refers to the producer of the unique loop exit condition (the condition that decides when the loop terminates). | ||
|
|
||
| - For ϕ gates and μ gates with multiple exits, this field is nullptr, as no single condition block drives their creation. |
There was a problem hiding this comment.
multiple exits -> multiple loop exits.
|
|
||
| This field identifies the block whose terminator provides the control predicate for the gate. | ||
|
|
||
| - For γ gates, it is the producer block of the condition that determines which input the γ selects. |
There was a problem hiding this comment.
Worth mentioning here that the current implementation of GSA ensures by construction that every γ gate has a single condition in a single block.
2 participants
This PR adds documentation for the GSA analysis.