(Naga) Implement OpSpecConstantOp for the SPIR-V frontend

[hasenbanck]

Description

Implement OpSpecConstantOp for the SPIR-V frontend.

This implementation solves all my problems that I had with SLANGC output.
But I couldn't implement all operations. The following are missing:

• Op::VectorShuffle, Op::CompositeExtract, Op::CompositeInsert => All work on non-scalars, which I can't get to work.
• Op::QuantizeToF16 => We don't support QuantizeToF16 in the SPIR-V frontend yet. I think the constant evaluator might also have problems with it.

It is possible to write GLSL that is valid SPIR-V but not valid SPIR-V for Naga. For example the amount of shifts can be defined with both signed and unsigned values in GLSL, but Naga expects, when validating the shader, an unsigned value. Sometimes the GLSL compiler also produces weird SPIR-V. For example:

const uint sp_uint_from_sint = uint(sp_sint);
const int sp_sint_from_uint = int(sp_uint);

will result in the folling ASM:

%sp_uint_from_sint = OpSpecConstantOp %uint IAdd %sp_sint %uint_0
%sp_sint_from_uint = OpSpecConstantOp %int IAdd %sp_uint %uint_0

Which will not be evaluated successfully, since we again mix signed and unsigned constants.

But I think it's still mergeable, since we implement a pretty big subset of OpSpecConstantOp.

Testing

I added two snapshot tests. One based on GLSL code and one in pure SPVASM, that tests more complex chained OpSpecConstantOps.

Squash or Rebase?

Rebase

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[hasenbanck]

I added a second commit to the PR that removes a workaround and instead uses the same approach as the GLSL frontend, by properly using the ConstantEvaluatorto evaluate the constant expressions. This is a more invasive change, so I decide it to add as a second commit, but could be spun into it's own PR if the reviewer think that's the better option.

This would enable us in a future PR to extend the ConstantEvaluator to have a mode for SPIR-V, that takes care for the corner cases that compiler could create (like the corner cases by the GLSL compiler described above).