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.