On Tue Nov 7 09:40:54 2023 +0000, Giovanni Mascellani wrote:
My feeling is that adding a `bitcast` operator creates less complexity than adding a field to a register type. But I can live with it, of course (and it's something that can be changed again in the future, if more compelling reasons arise). I'll leave this to Henri.
Well, MOV is effectively a bitcast operation in tpf/vsir, and that's how this MR implements CAST_BITCAST, of course. I don't think that's the issue as such here though.
vsir registers are bags of bits, with no inherent type; the "data_type" field of vsir instruction source and destination parameters determines how the instruction should interpret them, as mentioned by Conor. That's not how SPIR-V works, of course; SPIR-V values do have inherent types. The way we handle that for VKD3DSPR_TEMP registers is to declare them as 4-component vectors of 32-bit floats (largely for historic reasons; we could just as well pick 32-bit unsigned integers), and then bitcast those as needed when we do e.g. an IADD instruction on them.
In principle, I think the approach we use for VKD3DSPR_TEMP registers should work for VKD3DSPR_SSA registers as well. A slight complication is perhaps that DXIL has a more extensive set of type widths. I'm not entirely sure how consequential using e.g. a f32 SPIR-V value to store a f16 DXIL value would be; it doesn't seem ideal, but may not ultimately make much of a difference. Regardless, we can do slightly better with SSA values, and using the actual types would likely at least save a few bitcasts.
I think storing the data type along with the value ID in spirv_compiler_set_ssa_register_id() would be most consistent with how the rest of the SPIR-V backend works; we could even retrieve it again from spirv_compiler_get_register_info() in that case. I'm not sure what the complication Conor is referring to above is though? I think we can essentially just store "reg->data_type".