Allow constant references (to constant data), when they're valid SPIR-V. #586
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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):But a constant like
&(&1, &2)
isn't - its SPIR-V would have to be this, which doesn't pass validation:The problem isn't even
%ref_pair
, but%pair
itself:OpConstantComposite
must haveOpConstant...
fields, but not (global, i.e. module-scoped)OpVariable
fields (even if the storage class isPrivate
).This is pretty bizarre IMO, and I'm not 100% convinced it's intentional - it's possible the first case (with the nested
OpVariable
s) 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.