On Wed Jan 10 12:24:56 2024 +0000, Giovanni Mascellani wrote:
I guess this is wrong when `~0u` is returned (because the input is 0 or, for the `shi` variant, -1). It seems that the tests don't trip on this because the HLSL compiler already covers for this. The emitted code is something like:
vkd3d:3227409:trace:vkd3d_shader_trace firstbit_shi r0.x <v4:uint>, cb0[0].y <v4:int> vkd3d:3227409:trace:vkd3d_shader_trace ieq r0.y <v4:uint>, r0.x <v4:int>, l(-1) <s:int> vkd3d:3227409:trace:vkd3d_shader_trace iadd r0.x <v4:int>, l(31) <s:int>, -r0.x <v4:int> vkd3d:3227409:trace:vkd3d_shader_trace movc o0.w <v4:float>, r0.y <v4:uint>, l(-nan) <s:float>, r0.x <v4:float>So even if we emit `31 - ~0u` the code immediately makes up for that and converts that back to `~0u`. However this is still wrong, because we're supposed to translate the TPF code correctly even if the HLSL compiler isn't covering up for us. I realize that's orthogonal to what this MR is doing, but if you could fix that while you're at it it would be great. I guess the hardest part is getting a TPF shader without the fixup instructions. Maybe we'll have to edit the bytecode by hand for that. It would be nice to have a D3DBC/TPF assembler for instruction tests.
For testing I can NOP the fixup instructions away pretty easily in a hex editor. I'm not sure we should be making this change though, unless it fixes something. While it's not great to depend on the presence of fixup instructions (which DXIL also contains btw), if the backend can assume they are always present, then the code is not broken. @hverbeet?