Since we have -Wswitch, this forces the developer to update all relevant
switches when an enum case is added.
Places where the default is just a FIXME are left alone.
We apply distributivity to applicable expressions, specifically with
the following rewrite rules:
(x OPL a) OPR (x OPL b) -> x OPL (a OPR b)
(y OPR (x OPL a)) OPR (x OPL b) -> y OPR (x OPL (a OPR b))
((x OPL a) OPR y) OPR (x OPL b) -> (x OPL (a OPR b)) OPR y
(x OPL a) OPR ((x OPL b) OPR y) -> (x OPL (a OPR b)) OPR y
(x OPL a) OPR (y OPR (x OPL b)) -> (x OPL (a OPR b)) OPR y
where a, b are constants.
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).
Consistent with how D3DXFindShaderComment() allows looking up comments
by tag. This also makes it a little easier to move CTAB generation out
of d3dbc.c.
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.
The previous names "not normalised" and "fully normalised" have meanings
which are likely to change with time. OTOH including a description of the
normalisation level in the enumerant seems excessive. Relating
normalisation levels to shader model versions might be a reasonable
compromise.
