We shouldn't even have sampler variables left over by the time we get to sm1.
I am not sure if you meant to say "textures" instead of "samplers", but combined samplers appear like "Texture2D" in the CTAB, and `register(s·)` can be used in textures so that they reserve a particular sampler register:
I mean we shouldn't have HLSL_TYPE_SAMPLER variables left over. That's what my (out-of-tree) patches accomplish by lowering "separate" HLSL_IR_RESOURCE_LOAD to "combined" HLSL_IR_RESOURCE_LOAD instructions. I.e. removing the "sampler" variable from the instruction.
Arguably it's a bit awkward naming-wise to map HLSL_TYPE_TEXTURE to what sm1 (or GLSL, for that matter) calls a "sampler", but in terms of functionality I think it makes the most sense (e.g. HLSL_TYPE_TEXTURE has a dimension, as do sm1 samplers; HLSL_TYPE_SAMPLER does not.)
But we need an intermediate mapping from HLSL_REGSET_* to backend-specific register type enums anyway. Why does it matter how we map hlsl types to regsets?
I think that what I care about, rather than the name change, is that regsets can be used directly in the passes for allocating objects and for calculating deref offsets, both of which are backend-specific but have to be done before writing the actual bytecode.
I don't quite see how the mapping affects that, though?