Also, I'd like to stress this because it has come up before for other MRs, please don't pre-emptively add complications for issues that will only come up later; whether that's in a later patch in the same series or 400 patches later in the branch you're upstreaming from. Reviewers generally can't or don't want to look that far ahead, and it just ends up slowing the entire process down. Patches should make sense in isolation, at the point in time where they're introduced.
I agree strongly with this in general. I find myself often asking people to do this. But—and I'm sure I'm missing some perspective here—I don't see it as being a problem in this specific case.
Prematurely adding complications is a problem, I think, when I (as a reviewer) can't see how they're going to be used, and when I feel that there might be a better, simpler option that will possibly preclude the more complex code from *ever* being necessary.
I don't see an issue with the first part; I have the barest of knowledge about sm6 but I can tell that if it has SSA nodes, then we're introducing a vsir SSA node to translate from sm6 SSA nodes and that it's going to be used to translate to spirv SSA nodes.
As for whether there's a better, simpler option—I have a hard time personally seeing temps as simpler. This is partly because the SSA register type is just not complicated to begin with, and I don't expect the sm6 -> vsir or vsir -> spirv translations thereof to be complicated either. But it's also because passes on vsir (both the ones I'm anticipating related to sm1/sm4 output, and the ones Conor is talking about) are going to be distinctly harder to do on temps than on SSA nodes. [Some of this is armchair analysis, some of this may be bias from having just written the code, but some of it is influenced by comparing copy-prop to our other HLSL passes. Copy-prop is more complex and harder to reason with in general, and I think roughly models how we'd have to do passes on non-SSA.]
(And, well, I'm more than a little concerned about compilation speed, and compiled shader size, which makes me think that we likely *will* SSA nodes in vsir at some point. But I don't have any data to back that up, so I'll let go of that concern for now...)