HLSL offsetting

[Zebediah Figura]

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.