I'm not sure I completely understand what we're doing here. In principle VKD3DSPR_TEMP registers are vec4's and would get VSIR_DIMENSION_VEC4, at least before DXIL. Is the idea here that we want to allow (presumably mainly for DXIL) VSIR_DIMENSION_SCALAR temps, as long as we consistently access them that way?
Yeah, that's the idea. Of course it's up for debate (maybe I should have made that explicit; in general, my validator MRs are meant to be proposals for specifying the VSIR syntax).
At some point my idea was to mandate that TEMPs are always vec4 and SSAs are always scalar. But Conor's code already violates this, because some SSAs must be vec4 to allow assigning e.g. from sampling instructions; and as I already mentioned I plan to introduce a pass that converts SSAs to TEMPs, and while in principle I could make the TEMPs vec4 and use only `.x`, this feels a bit wasteful: it might be a better idea to explicitly signal to the backend that only the first component is to be used. I think the SPIR-V backend is already able to handle that gracefully. That's why I resolved in favour of allowing both SSAs and TEMPs to be both scalar and vec4, but it makes sense to require that they're consistent so that the semantic is clear.
I realize that can be troublesome: for example there are cases in which Conor's code uses temporaries, I don't know exactly why; but I guess it can be an additional burden checking that temporaries are used consistently in different instances. However, I think that having a clear and sensible syntax for VSIR is more important.
At any rate, as I said, that's a proposal, and discussion is welcome.