Takes care of transforming clip/cull system values from the Direct3D
convention of 2 4-component registers, into the SPIR-V/GLSL convention
of 8-element scalar float arrays.
This fixes SPIR-V validation errors in clip-cull-distance.shader_test,
as well as segfaults on Mesa 25.1.1-arch1.2 if those shaders are
executed regardless.
We create indexable temporaries of the appropriate size, and replace
accesses to clip/cull I/O signature elements with accesses to those
temporaries. The existing clip/cull signature elements are then replaced
with new scalar signature element arrays, and we copy the contents of
those I/O signature elements to/from the corresponding temporaries at
the start/end of the vsir program.
It is worth pointing out that the current implementation assumes that
every instance of the control point phase of a hull shader only writes
to the output registers of its control point, given by
vOutputControlPointID, and not to other control points. Shader
compilation will fail if that constraint is violated.
The main reason is to avoid making false assumptions in the code.
I don't know how that could be used, say, to introduce a security
bug, but I think validating untrusted input should be done by
default.
Conveniently this also acts as documentation for who needs to know
what fields we indeed expect to find in a well-known structure.
Constant numeric local variables can be used in places were literals are
expected if they're initialized with a static expression.
Storing such constant in ctx->static_initializers allows copy-prop to
handle such cases properly.
Emission of code into individual block instruction arrays was done to
enable construction of a control flow graph. A graph is constructed from
the flat instruction array in a later pass, so blocks are not needed.
It is possible to emit instructions directly into the array in struct
vsir_program instead of from sm6_function_emit_instructions(), but since
the patch constant function occurs first in DXIL hull shaders, this would
reverse the current order of functions in the flat array. That may be
acceptable, but it is left for a later patch in case any issues arise.
