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().
Unless the "native low precision" flag is enabled.
vkd3d_component_type_from_data_type() currently ends up doing this
mapping for us in the SPIR-V backend, but that's about to go away.
The HLSL compiler already did this; the TPF and DXIL parsers did not.
Previously spirv_compiler_emit_sample_info() was unable to correctly
handle VSIR_DATA_U32 destinations; the new version is arguably simpler
as well.
