Add workgroupuniform load built-in and analysis

[alan-baker]

Fixes #2586

• Add workgroupUniformLoad built-in function as
  new synchronization built-ins
• Rework synchronization built-ins to match style of other sections
• Modify rvalue expression table to split variable identifier rows into
  two
  • the first for when the load rule is not invoked maintains the
    incoming uniformity (that is pointers and references are uniform
    while they remain memory views)
  • the second for when the load rule is invoked retains the previous
    behaviour

[github-actions]

Previews, as seen when this build job started (6198f55):
WebGPU _{webgpu.idl | Explainer | Correspondence Reference}
WGSL _{grammar.js | wgsl.lalr.txt}

[alan-baker]

Open question: do we want a version of workgroupBroadcast based on local invocation index?

[dneto0]

From the 2022-11-15 meeting, the committee agreed to proceed with workgroupUniformLoad.

[dneto0]

workgroupBroadcast is not yet agreed by the committee.

workgroupUniformLoad needs further qualification: The result is uniform only if the pointer argument is uniform. Details posted to the issue.

[dneto0]

Committee 2022-11-15 did not (yet) agree to workgroupBroadcast

[dneto0]

Thanks!

[dneto0]

Yep.
This aligns uniformity analysis with how we do type-checking and the conceptual model of how execution/evaluation occurs.
This is the end result of what @jimblandy suggested, and it works out really nicely.

[dneto0]

Would also fix #3602

[dneto0]

I think there's a technical problem with the pointer desugaring, due to incomplete capture of values of variables that may change between the pointer declaration and its use.

[dneto0]

Missing words here? Each identifier that resolves to a let-declaration ...

Interestingly, it doesn't matter what order the substitutions are made.

Might want to add a note:

The order of substitutions is not significant, always settling with the same final result.

[dneto0]

Is there a technical problem here? Because the indexing into those desugared pointers could have its uniformity properties changed. They may refer to variables that have had full assignments on them in the meantime, or vice versa. Basically, you have to properly capture the values of variables at the point of recording the initializer for the let-decls.

E.g. see how 'foo' evolves through desugaring. Yet, variable i receives a full assignment that makes it uniform halfway through the function.

@group(0) @binding(0) var t: texture_2d<f32>;
@group(0) @binding(1) var s: sampler;

fn foo(parami:i32) -> vec4<f32> {
   var i = parami;
   var v = array<i32,2>(-1,1);
   let p = &v[i];
   if (v[i] > 0) {
      return textureSample(t,s,vec2(.0));  // causes uniformity error.
   }
   i = 0;   // full assignment
   if (v[i] > 0) {
      return textureSample(t,s,vec2(.0)); // no uniformity error
   }
   return vec4<f32>();
}

fn foo_via_pointers(parami:i32) -> vec4<f32> {
   var i = parami;
   var v = array<i32,2>(-1,1);
   let p = &v[i];
   if (*p > 0) {
      return textureSample(t,s,vec2(.0));  // should cause uniformity error.
   }
   i = 0;  // full assignment
   if (*p > 0) {
      return textureSample(t,s,vec2(.0)); // should still cause uniformity error
   }
   return vec4<f32>();
}

fn foo_via_pointers_desugared(parami:i32) -> vec4<f32> {
   var i = parami;
   var v = array<i32,2>(-1,1);
   let p = &v[i];
   if (*(&v[i]) > 0) {
      return textureSample(t,s,vec2(.0));  // should cause uniformity error.
   }
   i = 0;  // full assignment
   if (*(&v[i]) > 0) {
      return textureSample(t,s,vec2(.0)); // should still cause uniformity error
                                          // but it won't
   }
   return vec4<f32>();
}

@fragment
fn main(@builtin(position) p: vec4<f32>) -> @location(0) vec4<f32> {
  return foo(i32(trunc(p.x)));
}

[alan-baker]

Good catch. The desugaring should be capturing the values of mutable variables other than the root identifier.

[dneto0]

LGTM.
Thanks for handling this delicate rule!

[dneto0]

Right. It has to be post-order because you want to capture the most deeply nested item first.

Then I started thinking: Does this have to specify left-to-right traversal as well? I don't think it does.
Interestingly, the desugaring doesn't have to produce and equivalent value, just an equivalent uniformity property.
And the only mutable variable that can have its uniformity affected is a function-scope var. And the analysis only updates that uniformity property in an assigment statement in the same function. So this desugaring is sufficient.

If we actually wanted to capture the right value, we'd also have to capture the values and side effects of function calls. That's a lot more work, and not needed here.

[dneto0]

nit: Might be worth emphasizing the "not", either italics or bold.

[dneto0]

An example suggested from internal review:

Consider let p = &y[x[10]];

In this case:

• one MVE is x[10] and it does have the load rule applied. The root identifier is x.
• the other MVEs are y[x[10]] and &y[x[10]], with root identifier y, but neither of those have the load rule applied during type checking.

[jrprice]

The mechanics of this LGTM, and aligns with how we plan to implement this in Tint.

We can also remove the special-case for arrayLength from the analysis, but happy for that to be a follow-up change if preferred.

[dneto0]

Discussed internally at Google:

• This can be expanded in future when more general pointers are added.
  • In particular, when adding pointer-to-workspace params, they can be desugared into fresh module-scope variables in workgroup address space; where "fresh" means each pointer formal param in the source corresponds to a distinct module-scope variable. That's sufficient for analysis because we assume the aliasing restrictions are still in place. The variable would be seen as non-uniform because it's still mutable and shared among invocations. There may be other ways to handle this too.