It's not obvious what this last remaining use of
sm6_parser_require_space() is preallocating space for, and that's as
good of a reason as any to get rid of it.
Only calls to sm6_parser_add_instruction() where we are using the
returned vkd3d_shader_instruction are checked for, since these return
values might cause NULL dereferences if unchecked.
Other calls to sm6_parser_add_instruction() can be left alone since the
error is still recorded via sm6->p.status.
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.