Re: [PATCH v2 0/4] MR174: Consolidate the TPF and d3dbc handling code.

[Henri Verbeet (＠hverbeet)]

> > This is what I originally thought, but I'm having slight second thoughts now. The thing is that the tradeoff is now you need a new IR for every bytecode language you have, which in our case means at least sm1, sm4, and eventually I think sm6. That's a lot of extra support code to add. Consider how much we'd need to add by putting that intermediate step into HLSL -> smX translation. The advantage of making v_s_i the IR is that you don't actually need any of that.
>
> You mean that you'd have just `v_s_i` and every frontend and backend deals directly with it, including for very syntactical things like assembling and disassembling? I don't feel really convinced, it seems to me that you'd have to encode su much stuff in `v_s_i` that each time you need to change something (for example to allow for a new language) the changes can have repercussions in each other language frontend or backend.

Probably not for everything. E.g., I suspect the DXIL disassembler probably shouldn't go through the common IR. But fundamentally, I think that's much of the point of having a common IR. DXIL support, though not quite done yet, is perhaps a decent example there. Without going through the common IR, that would require duplicating a decent chunk of the code currently in spirv.c. There's some work required upfront to make the common IR suitable for DXIL, but ultimately the resulting code should be more maintainable.

-- 
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/174#note_31740