On Wed Nov 8 16:08:11 2023 +0000, Henri Verbeet wrote:
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?
Perhaps alternatively, we could also consider storing SSA value types as an array in the vkd3d_shader_desc structure, somewhat similar to the approach taken for block names.