On Fri Nov 3 01:49:39 2023 +0000, Henri Verbeet wrote:
This really makes me think that it's time to unlock VSIR from SM4 and
let it live its own life. We shouldn't block the MR on this, sure, and separating VSIR and SM4 will probably be a pain because of the disassembler, but I don't think the disassembler should be the main decision factor for an IR. It depends on what you have in mind exactly, I guess. There's certainly an argument for introducing "split" variants of these instructions with two outputs like IMUL and UDIV, but also e.g. SINCOS, particularly since we're effectively splitting them for SPIR-V (and GLSL) output anyway. I don't think that needs to be an issue for the disassembler though; we can just keep the complex instructions in the IR, and lower them to the simpler variants before producing output, much like we intend to do for some of the more complex texturing instructions from shader model 1-3.
In a similar vein, I didn't add a `DREM` to go with `FREM`. Separate opcodes for `double` are redundant because we have the register data types. I'm not planning on adding `half` variants for native 16-bit support either. To keep things consistent I think we should normalise all TPF `double` variant opcodes to `float` opcodes, and validate the register data types.