Rebased, I also applied all requested changes except changing the names of the object regsets, namely `HLSL_REGSET_S`, `HLSL_REGSET_T`, and `HLSL_REGSET_U`, which is a thing I would like to bikeshed a little more.
I think that these values of `enum hlsl_regset` should indeed map to a single type of register, as in the function `hlsl_regset_name()`, save for `HLSL_REGSET_NUMERIC`.
I am starting to see we are converging to define a clear point in `hlsl_emit_bytecode()` where we start performing backend-specific operations over the IR, which is after the last call to `compute_liveness()` (well, it is still pending to move the `transform_deref_paths_into_offsets` pass forward for this to hold 100% true, but lets assume that).
This makes sense to me, since lowering passes and register allocation, which happen after that point, **have** to contain backend-specific details.
While `reg_size` is backend-specific, it is only **precomputed** at the time the type it is generated, but not used after this backend-specific point, same for the introduced `regsets` in general.
So, I don't see much reason to have them represent another level of indirection using values such as `HLSL_REGSET_RESOURCES` since they are used pass this point of backend-specific-ness.
Also, with the current scheme, it is fairly easy to add new regsets or object types to a different one if required by the backend. It is just a matter of adding a new entry to `enum hlsl_regset`, and modifying `hlsl_type_get_regset()` and `hlsl_regset_name()`.