On Mon Nov 6 11:43:12 2023 +0000, Giovanni Mascellani wrote:
It makes an odd kind of sense. LLVM treats bool as a 1-bit int, so a
signed bool has only a sign bit, and `true` is `-1`. I could add a new instruction, but `spirv_compiler_emit_alu_instruction()` must handle bool anyway, so I see no issue in treating bool as a 1-bit int and passing it to numeric handlers. Oh, right, it makes sense at the DXIL level. But please add a comment in the code, I don't think it's evident. Also, you should probably check that if the instruction is not `itof` then it is `utof`, because at that point in control flow you only have checked that source and destination types. And similarly for the `double` branch.
`CAST_SITOFP` supports bool and maps to `ITOF`.
Yes, but this happens in a later commit, even if it's the same MR. I don't insist to change it for this MR, but in general please try to order commits, even inside a single MR, in such a way that there is no dead code. This usually means implementing the frontend changes first and then backend changes.
Thus far I've always changed the SPIR-V backend before the DXIL frontend, but it can certainly be done the other way around: add the instruction and allow compilation to fail in the backend until patched.