The assumptions the I/O normaliser makes on its input program are
rather intricated. In theory the VSIR validator checks should be
strong enough, but the validator isn't run by default anyway.
Whether the TPF parser validation is strong enough is not
completely clear to me, and considering that the I/O normaliser
could end up being used on different programs as well it's
probably better to revalidate locally just in case.
Commit 4717775abb removed the code turning
the corresponding DCL_INPUT instructions into NOPs, presumably because
vsir_program_remove_io_decls() now already removes them. That function
only removes the instructions though, not the declarations as such; we
now need to remove these from the "io_dcls" bitmap instead.
Otherwise ubsan reports runtime errors such as:
libs/vkd3d-shader/ir.c:4731:5: runtime error: null pointer passed as argument 1, which is declared to never be null
Otherwise when passing "-fsanitize=undefined" to the compiler, ubsan
reports such as:
libs/vkd3d-shader/ir.c:3794:5: runtime error: null pointer passed as argument 1, which is declared to never be null
The two branches do essentially the same thing, but in different
ways and each one omitting different details. In particular there
is no need to discriminate on whether the register is a relative
address, we can just copy the NULL pointer.
The hull shader control point normalisation pass already ensures
that output registers in the control point phase have two
indices (the control point index and the register index).
It makes the code quite longer, but also easier to read and extend
with further properties.
A (desirable) side effect of this commit is that it is checked
whether I/O register types are legal depending on the shader type
and phase, while before that was assumed.
This commit introduces enum vsir_io_reg_type and enum vsir_phase
which shadow enum vkd3d_shader_register_type and enum
vkd3d_shader_opcode, with the goal of making the data tables
smaller.
Sometimes SM1-3 shaders contain write masks that exceed the
signature element masks. That happens because SM1-3 shaders do not
have a concept of signature and signature masks, and OTOH aren't
always able to express any given write mask.
In VSIR we don't want to deal with I/O register masks exceeding the
corresponding signature element mask or usage mask, because, for
instance, for higher shader models it can complicate dealing with
DCL_INDEX_RANGE. In order to have uniform rules for all shader
models we normalise masks coming from SM1-3 shaders.
We don't do that normalisation when disassembling, in order to
preserve the expected output.
