One of the effects of I/O normalization, when it was introduced, was to shift
the writemask of all semantics to become 0-based—e.g., to convert .yz to .xy.
It did this by modifying the shader code, but did *not* modify the signature
masks.
The SPIR-V compiler, at the time, used both the write mask on the dcl_input
instruction and the signature masks. It also, due to the requirements of the
SPIR-V format, performed the same normalization, left-shifting each mask to
become zero-based. Despite this normalization now being performed earlier in
the aforementioned VSIR pass, the handling in the SPIR-V backend was never
removed.
When 66cb2815f0 was written, I either incorrectly
assumed that the signature mask was equal to the dcl_input write mask (at least,
in any well-formed shader), or (less likely) I noticed that the discrepancy
might exist but believed that the left-shifting normalization performed by the
spirv compiler covered all cases.
In either case it turns out there is one case where the difference was not
handled by the spirv compiler either. That is the case of a varying which has
a fixup function and therefore needs a private variable, which is currently true
for the SV_VertexID, SV_InstanceID, and SV_IsFrontFace varyings.
Thus, if one of those varyings has a signature mask other than .x, we currently
copy the SPIR-V builtin value to the relevant component of the private variable,
but subsequent code will load from the .x variable due to the normalization done
by shader_src_param_io_normalise().
This fixes a regression introduced by 66cb2815f0.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57433
So that it can be used in other contexts as well. And so that
register allocation can be run also when there is no need to update
or create DCL_TEMPS instructions.
