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.