Allow constant references (to constant data), when they're valid SPIR-V.

[eddyb]

This is trickier than it should reasonably be, because of some SPIR-V limitations.

A constant like &&123 is valid in SPIR-V and generates something like this (types omitted for brevity):

        %int_123 = OpConstant _ 123
    %ref_int_123 = OpVariable _ Private %int_123
%ref_ref_int_123 = OpVariable _ Private %ref_int_123

But a constant like &(&1, &2) isn't - its SPIR-V would have to be this, which doesn't pass validation:

    %int_1 = OpConstant _ 1
%ref_int_1 = OpVariable _ Private %int_1
    %int_2 = OpConstant _ 2
%ref_int_2 = OpVariable _ Private %int_2
     %pair = OpConstantComposite _ %ref_int_1 %ref_int_2
 %ref_pair = OpVariable _ Private %ref_pair

The problem isn't even %ref_pair, but %pair itself: OpConstantComposite must have OpConstant... fields, but not (global, i.e. module-scoped) OpVariable fields (even if the storage class is Private).

This is pretty bizarre IMO, and I'm not 100% convinced it's intentional - it's possible the first case (with the nested OpVariables) was never meant to be legal either.

---

Regardless of whether the rules make sense or not, this PR accounts for them, and you can see in the UI tests some simple examples what is allowed and what isn't (the == examples were the original motivation for this PR).

I've even tested that adding multiple extraneous references to the color constants in mouse-shader still works, but I suspect the loads get constant-folded anyway, so it's not much of a test.

[khyperia]

what the fuck

[OpVariable instruction spec]: Initializer is optional. If Initializer is present, it will be the initial value of the variable’s memory content. Initializer must be an from a constant instruction or a global (module scope) OpVariable instruction.

[khyperia]

❤️ ty

[khyperia]

yeah gosh, this would be nice, been dreaming about this possibility for ages, haha - seems like with this system, we're actually kind of close to being able to do so

[khyperia]

Just curious, are there any types that cannot be made by OpUndef? Intuitively, there absolutely should be, but I don't think the spec actually mentions anything.

[khyperia]

nit: around their values?