I do think that hlsl_type_get_regset() feels conceptually broken, though, and HLSL_REGSET_VOID as well.
Yep, the problem is that in following patches there are many more places where getting rid of `HLSL_REGSET_VOID` would mean having to add a check for if a variable is struct or not (and it can be quite easy to forget to add one). That's why, at first, I just mapped structs to `HLSL_REGSET_NUM` and now `HLSL_REGSET_VOID` serves that purpose.
The point is that any callers of hlsl_type_get_regset() either don't need to handle structs, or need to do something special to handle structs. In the case of sm1 "something special" might mean "assuming they're always numeric", but that's still something we want to spell out explicitly. HLSL_REGSET_VOID should never actually be interpreted, and as a corollary shouldn't exist.
Also, since now `hlsl_type_calculate_reg_size()` calls `hlsl_type_get_regset()` the latter also has to consider `HLSL_TYPE_PIXELSHADER`, `HLSL_TYPE_VERTEXSHADER`, `HLSL_TYPE_STRING`, and `HLSL_TYPE_VOID` as inputs.
hlsl_type_calculate_reg_size() really just shouldn't exist, at least not in its current form. We should never care about the register size of a variable that has any of those types. I think we eventually want to stop stashing reg_size in the type itself and just make hlsl_type_calculate_reg_size() a pure function. Probably it should just duplicate hlsl_type_get_regset() for now.