In order to allocate it properly we have to ensure it is the first
register to be processed. The current algorithm fails to do so, so
a more explicit approach is introduced.
Primarily to avoid -Warray-bounds warnings from newer gcc, specifically
for the first vsir_instruction_init() call in vsir_update_dcl_temps().
This seems to be a false positive created by the interaction between
vsir_program_iterator_insert_after() and vsir_program_iterator_next()
error handling; it may be possible to avoid that by rearranging things,
but it doesn't seem worth it.
The SPIR-V, GLSL and MSL backends implicitly handle swizzles on
immediate constants, but the TPF and d3d-asm backends assume a default
swizzle. In principle there's no reason those couldn't support swizzles
on immediate constants, but they're a little pointless.
We will move the dst_params and src_params fields from struct
vkd3d_shader_instruction_array to the vsir program next, so we need to
widen the scope of this pointer to the whole vsir program.
We stop storing a shallow copy of the vsir_program.instructions on
control_point_normaliser.instructions since
vkd3d_shader_instruction_array is not meant to be copied by value, which
is evidenced by the fact that the struct has to always be copied back to
program->instructions before returning.
We have a number of vsir operations which should take a signed type, but
which the DXIL parser currently emits unsigned types for. For example,
ISHR.
In the SPIR-V backend, we translate ISHR to OpShiftRightArithmetic,
which is specified as filling the most-significant bits of the result
with the sign bit of the "Base" operand. For an unsigned type, that
would technically be 0. In practice, implementations like radv/Mesa seem
to fill with the most-significant bit of the "Base" operand for unsigned
types, but arguably that could be considered a bug. Alternatively, the
wording in the specification is just unfortunate; SPIR-V does generally
take the position that signedness of operands should be irrelevant for
almost all operations. Either way, it seems best to avoid using
OpShiftRightArithmetic with unsigned types.
For a target like MSL, allowing ISHR to take an unsigned source operand
is just inconvenient; we'd have to introduce bitcasts to achieve the
desired behaviour, instead of simply using msl_binop().
