gmascellani at codeweavers.com
Tue Jun 14 09:49:43 CDT 2022
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
enum hlsl_selector_type type;
unsigned int field;
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++).
More information about the wine-devel