[naga spv-out] Ensure loops generated by SPIRV backend are bounded

[jamienicol]

Connections
Partial fix for #6572 (can tick SPIR-V off, still GLSL to go)
Related to #6929: that updated the previous MSL workaround to use the 64bit counter approach, and added the workaround for HLSL

Description
If it is undefined behaviour for loops to be infinite, then, when encountering an infinite loop, downstream compilers are able to make certain optimizations that may be unsafe. For example, omitting bounds checks. To prevent this, we must ensure that any loops emitted by our backends are provably bounded. We already do this for both the MSL and HLSL backends. This patch makes us do so for SPIRV as well.

The construct used is the same as for HLSL and MSL backends: use a vec2 to emulate a 64-bit counter, which is incremented every iteration and breaks after 2^64 iterations.

While the implementation is fairly verbose for the SPIRV backend, the logic is simple enough. The one point of note is that SPIRV requires OpVariable instructions with a Function storage class to be located at the start of the first block of the function. We must therefore do an initial pass over the function to generate the IDs used for the loop counter variables, and ensure the corresponding OpVariable instructions are emitted at the start of the function. Then finally during the main code-generation pass we can refer to these IDs.

As this may negatively impact performance, this workaround can be disabled using the same mechanism as for other backends: eg calling Device::create_shader_module_trusted() and setting the ShaderRuntimeChecks::force_loop_bounding flag to false.

Testing
Inspected snapshot test changes. Ensured validation still passes

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file. (also added the HLSL fix from [naga msl-out hlsl-out] Improve workaround for infinite loops causing undefined behaviour #6929)

[jimblandy]

We think there might be a nicer way to generate the temporary variables as we go, rather than making a separate pass over them beforehand.

[jamienicol]

We think there might be a nicer way to generate the temporary variables as we go, rather than making a separate pass over them beforehand.

Indeed, the pass to generate a Function's body, ie Function::write_function_body() already occurs prior to Function::to_words() - which writes instructions for the local variables etc, and then writes the body. So there's no need for yet another pass.

Patch updated

[teoxoy]

Looks great!

[teoxoy]

@jamienicol looks like there are some conflicts now

Feedback was addressed