Depending on the casted operand, the generated values can be
ICB, IDXTEMP or GROUPSHAREDMEM.
The cast decoding code is entirely moved to the second pass, so
that we avoid abusing registers to temporarily store other data.
The stored value is never read, the caller will overwrite it with
the SSA register generated by the whole DXIL instruction.
Since the helper is always used for UINT instructions, change and
rename it accordingly, so we don't have the problem of finding out
which data type to use.
sm6_metadata_get_float_value() already calls sm6_value_is_constant()
itself, and some compilers (rightly) emit a warning that the conversion
of UINT_MAX to float changes the value.
And other related identifiers similarly.
Currently we use VALUE_TYPE_ICB to indicate a raw chunk of data
(which can be used as an immediate constant buffer, but also for
initializing an indexable temporary) and VALUE_TYPE_REG with
register type VKD3DSPR_IMMCONSTBUFFER to indicate an actual ICB
register.
Since we are now switching to represent the register type directly
in the SM6 value, it seems sensible to use VALUE_TYPE_ICB for an
ICB register. Indeed, since what we're currently describing with
VALUE_TYPE_ICB is not necessarily related to an ICB register, it
makes sense to use a more general name, which is therefore being
introduced with this commit.
VALUE_TYPE_UNDEFINED means that a value is explicitly undefined,
equivalently to what was first represented with is_undefined.
VALUE_TYPE_INVALID will be introduced for values that arise from
invalid programs.
Currently structured TGSM loads are encoded to something like this:
ld_structured sr12 <s:float>, sr1 <s:uint>, l(0) <s:uint>, g0[sr1 <s:uint> + 0] <s:float>
Notice how the TGSM offset, expressed by sr1, is encoded twice in
the instruction. In TPF there is no expectation of two indices
in the resource source, so let's avoid producing it for DXIL as
well. The same instruction will therefore become:
ld_structured sr12 <s:float>, sr1 <s:uint>, l(0) <s:uint>, g0 <s:float>
