It's not particularly clear to me why 1/9 is here just from reading it—which isn't to say it's wrong or looks wrong, but it'd be nice to have that clarification.
In SM 5.0 resources can be members of structs so, for instance, in order to write a resource store, we cannot longer rely on the deref->var->data_type (which is a struct) but we need the data type of the part actually pointed by the deref, which we lose once we lower the path into a single offset. That's why we have to store it somewhere (deref->data_type here, and accessed through hlsl_deref_get_type()).
I'm not sure I can say 1/9 is going in the wrong direction, but it's going in a direction perpendicular to the right one. We should eventually be able to get to a state where the only thing in hlsl_deref is the path itself, and the type / register set is determined by the user (i.e. which field of a hlsl_resource_load it is).
I know I have said this a couple of times before but at this point I am inclined to keep lowering the paths into an offset as we do now, instead of trying to get the whole path into d3dbc.c and tpf.c. i.e. conserving replace_deref_path_with_offset().
The only benefit I see of propagating the deref path is that we wouldn't need this `data_type` nor the `offset` field, but I see several drawbacks:
- We would have to implement constant folding at the bytecode level in d3dbc.c and tpf.c, since (besides relative-addressing) offsets must result in a single constant offset. We can do that in hlsl_offset_from_deref() though. - We wouldn't be able to rely on DCE to get rid of the path nodes in the output bytecode, which won't be used by instructions after the aforementioned offset folding. They would be allocated nevertheless, and also bloat the output and the assembly. - Relative-addressing expects a single temp to be used as register index, not a whole path, so to create it, we would have to add additional bytecode instructions in both d3dbc.c and tpf.c, using additional temp nodes to store temporal values.
I no longer see moving the paths forward terribly difficult, but is it worth it?
Anyways, I think we can go on with this MR before reaching a final conclusion in that regard.