I think storing the data type along with the value ID in spirv_compiler_set_ssa_register_id() would be most consistent with how the rest of the SPIR-V backend works;
This is what I had originally, but I couldn't remember why I removed it while fixing the last few issues. Now I see the problem. DXIL occasionally emits forward-referenced values. It includes an extra type operand in that case, so we do know the type of the source value. The problem in the backend is when the type is written alongside the id just written, it's too late. An earlier instruction has already accessed the id with no type available. If that was a bitcast `MOV` it will fail.
We may be getting a bit ahead of ourselves here, but what do those forward references look like on the DXIL, vsir, and SPIR-V levels? In particular, I imagine we'll need to call spirv_compiler_set_ssa_register_id() in such cases as well, in order to create the mapping between the vsir and SPIR-V SSA IDs?