Add --spirt-passes and a reduce pass for replacing ops with their inputs/constants.

[eddyb]

Right now the supported "reduction rules" are very limited (using Rust-y pseudosyntax for examples):

• OpCompositeExtract on the result of OpCompositeInsert - e.g. (a, b).0➡️a
• signedness-change OpBitcast on constants - e.g. 5i32 as u32➡️5u32
• OpSwitch on a bool-derived int - e.g. match (cond as u32) {...}➡️if cond {...} else {...}
  • this is technically not a DataInst reduction, but a ControlNode one, and it feels a bit hacky, but if we had an easier way to confirm the range of the integer being OpSwitched on, it would be equivalent to transforming switch x { case 0: A; case 1: B; } to if x != 0 {B} else {A} (and then the job of reduce is to simplify the x != 0 to an existing bool)

(these were chosen by the motivation to make for i in 0..n optimize as well as the equivalent while)

However, the real power of this reduce pass is in the ways in which it plumbs dataflow through conditional control-flow and loops - using the pair example:

• if ... { (a, b) } else { (c, d) }.0➡️if ... { a } else { c }
  • this further becomes "unconditional" if e.g. a and c are the same, or one of them is OpUndef
• x = (a, b); loop { use(x.0); ... x = (c, d); }➡️x_0 = a; loop { use(x_0); ... x_0 = c; }
  (the mutation above is purely notational, that's "loop state", aka φ across a backedge in SSA)
  • this further becomes "loop invariant" (i.e. replaced with the initial value) if unmodified by the loop

Because of the restriction on "transforming away computation" without generating new SPIR-T DataInsts, at the SPIR-V level only OpPhis may be newly generated, everything else is reused or even removed.
(and OpPhis, aka "φ nodes", have the opportunity to go unmodified all the way down to the driver generating machine code and allocating registers based on the SSA dataflow, so it's hard to estimate their "true cost")

---

(EDIT: a much simpler fuse_selects pass was also added after the PR was opened, to "seal the deal" on for loops, by combining two if-elses with identical conditions - also see example lower below)

---

Either way, this PR is powerful enough to deal with for i in 0..n:

(click to see the shader code used to get these outputs)

#[spirv(fragment)]
pub fn main_while(#[spirv(flat)] n: u32, output: &mut u32) {
    let mut i = 0;
    while i < n {
        *output += i;
        i += 1;
    }
}

#[spirv(fragment)]
pub fn main_for(#[spirv(flat)] n: u32, output: &mut u32) {
    for i in 0..n {
        *output += i;
    }
}

_{Note: this SPIR-T is not from --dump-spirt-passes but rendered from the output of spirv-opt (sadly that process itself, which involves SPIR-T restructurization, results in an if _ { (true, ...) } else { (false, ...) } that's not in the SPIR-V itself)}

while	for	for --spirt-passes=reduce,fuse_selects

---

And this is what --dump-spirt-passes itself looks like, for the example above:

(there's still some stray OpNops, a funny limitation of SPIR-T's linked lists accidentally not supporting removal yet, but in most cases whole Blocks of unused instructions can be removed, so it's not that bad)

[oisyn]

It's missing a changelog entry :)

[eddyb]

It's missing a changelog entry :)

I'm going back and forth on actually landing this right now. It's opt-in on top of SPIR-T itself being opt-in (you have to set something like RUSTGPU_CODEGEN_ARGS="--spirt --spirt-passes=reduce,fuse_selects", and highly experimental, more of a demonstrator than "oh we fixed this and that".

One argument I could see, though, is it can get more testing this way. I'll add a changelog entry for --spirt-passes at least and not go into detail about the specific passes.