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()).
Aaah, right.
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.
I'm not sure I understand. Yeah, we have to do some math, but it's not particularly complex?
- 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.
Yeah, but that's kind of orthogonal. We have those "dead" nodes in the output anyway, right now, and in order to get rid of them we need to either add a constant offset field to hlsl_ir_load, or do DCE on the vsir layer. Either solution can be ported to the paths approach, though.
- 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.
It'll need a LOAD to be translated to potentially multiple vsir instructions, but it's not clear to me that's a bad thing.
I no longer see moving the paths forward terribly difficult, but is it worth it?
For the sake of simplicity, I think probably.
Anyways, I think we can go on with this MR before reaching a final conclusion in that regard.
Yes, definitely.