These correspond to the DXIL SDiv and SRem instructions, for which division by
zero is undefined. Division by zero is also undefined for DXIL UDiv and URem;
addressing those is slightly more involved.
Callers to shader_glsl_print_register_name() expect this. In particular, this
fixes translation of instructions such as
store_uav_typed u0.xyzw, vThreadID.xyxx, l(2.00000000e+00)
which is currently translated as the invalid
imageStore(cs_image_0, ivec4(gl_GlobalInvocationID).xy, vec4(uintBitsToFloat(0x40000000u), 0, 0, 0));
More recent versions of the Vulkan/SPIR-V validation layers have started
to complain about our usage of "SequentiallyConsistent" in our SPIR-V
output. Specifically, VUID-StandaloneSpirv-MemorySemantics-10866 "Memory
Semantics with SequentiallyConsistent memory order must not be used in
the Vulkan API".
The SPIR-V specification says: "If the declared memory model is Vulkan,
SequentiallyConsistent must not be used." However, we're using the
GLSL450 memory model with SPIR-V 1.3, and "Vulkan" is not available
before SPIR-V 1.5.
The Vulkan specification says "Sequentially consistent atomics and
barriers are not supported and SequentiallyConsistent is treated as
AcquireRelease. SequentiallyConsistent should not be used." in the
"Shader Memory Access Ordering" section.
Those don't quite add up to the "... must not be used in the Vulkan
API", from the validation layers, but it does seem clear that
SequentiallyConsistent isn't actually supported. On the DXIL side, when
targetting SPIR-V with dxc, the generated SPIR-V uses the
"None"/"Relaxed" memory semantics. I wasn't immediately able to find a
reference for what seq_cst is supposed to mean in the context of DXIL,
but "None"/"Relaxed" does seem consistent with how the HLSL
atomic/interlocked intrinsics are expected to behave, as well as with
our behaviour for tpf shaders.
