On 6/14/22 09:49, Giovanni Mascellani wrote:
Hi,
I finally managed to read through your messages, and it seems that we have a sort of agreement for trying with structured dereferences, which I agree with too.
Il 10/06/22 23:13, Zebediah Figura ha scritto:
On the other hand, the version of (b) I imagine changes hlsl_deref to:
struct hlsl_deref { struct hlsl_ir_var *var; unsigned int route_len; struct hlsl_src *route; };
Where route is intended to be a variable size array of component offsets.
I was envisioning something more explicit, but this is simpler, so my guess is that this is what we want.
I can live with Francisco's proposal, but my preference would be for something like:
enum hlsl_selector_type { HLSL_SELECTOR_SUBSCRIPT, HLSL_SELECTOR_FIELD, };
struct hlsl_selector { enum hlsl_selector_type type; union { hlsl_src *subscript; unsigned int field; }; };
struct hlsl_deref { struct hlsl_ir_var *var; unsigned int path_len; struct hlsl_selector *path; };
This way field indices are kept as actual numbers, not other nodes that have to resolve to a constant uint value. In general I like data types to constrain as much as possible to the valid values that you can store in them (and I don't think there is any way in HLSL to make a dynamic reference to a field of a structure, like it is possible in C++).
I agree in principle, but this does make the structure more complex to deal with. I'm inclined to stick to Francisco's proposal for now and just store it as a constant either way. We could certainly revisit it later, though.