Fix the way IR "regions" store conditions (#2216)

As part of generating high-level-language code, we have a pass that
builds a data structure representing structured control-flow `Region`s
and their nesting relationship. That data structure is then used
when emitting control-flow statements for the body of a function.

There are `Region` subtypes coresponding to different kinds of control
flow constructs. Both the `IfElseRegion` and `SwitchRegion` subtypes
were implemented to store a reference to the branch condition direclty
in the `Region`. This turns out to be the root cause of the problem.

After the nested `Region` structure is constructed, we have an IR pass
that uses the region hierarchy to detect and fix problems where the
implicit "scoping" rules of SSA form are incompatible with the scoping
rules that will be in effect when those regions are emitted as
high-level-language control-flow statements.

A bug arose when one of the SSA values that required the scoping fix
was the branch condition of an `if` statement. While the IR pass did
what it was supposed to and replaced the operand to the `IRIfElse`
instruction, doing so did not change the cached condition in the
corresponding `IfElseRegion`, and thus didn't effect the way code
got emitted for the `if(...)` condition in HLSL.

The fix here is simple: the relevant `Region` subtypes now store a
pointer to the relevant control-flow instruction rather than to
the branch condition. The emit logic can thus fetch the correct
condition from the control-flow instruction at the time it emits an
`if` or `switch`.

Note: We do not need to have the same worries around the `IRIfElse`
or `IRSwitch` instructions, nor for the `IRBlock`s that the `Region`s
still store. The passes that come after the `Region`s get created are
not supposed to alter the CFG in any way, because otherwise they would
risk changing/invalidating the `Region` structure.

Similarly, this change doesn't modify the `IRInst`s refernced in the
`Case`s for a `SwitchRegion` under the assumption that these must
always be literal integer constants, and thus cannot be changed out.

Co-authored-by: jsmall-nvidia <jsmall@nvidia.com>

0 files changed, 0 insertions, 0 deletions