Re: [PATCH v2 0/7] MR124: vkd3d-shader/hlsl: Introduce hlsl_ir_index, part 1/2.

[Zebediah Figura (＠zfigura)]

Zebediah Figura (@zfigura) commented about libs/vkd3d-shader/hlsl_codegen.c:
> -
>    return false;
> - list_add_before(&instr->entry, &load->node.entry);
> - hlsl_replace_node(instr, &load->node);
> -
> - return true;
>
> +}
> -
>
> +/* hlsl_ir_index nodes are a parse-time construct used to represent array indexing and struct
> -
> - record access before knowing if they will be used in the lhs of an assignment --in which case
> -
> - they are lowered into a deref-- or as the load of an element within a larger value.
> -
> - For the latter case, this pass takes care of lowering hlsl_ir_indexes (and index chains) into
> -
> - individual hlsl_ir_loads.
> -
> - It is worth noting that the generated hlsl_ir_loads don't load from a copy of the variable loaded
> -
> - at the beggining of the index chain, but from the same variable instead, because it is assumed
> -
> - that the value of the variable won't change between the the hlsl_ir_load instruction and the
> -
> - hlsl_ir_index. */

I don't like this assumption. Isn't this exactly the kind of thing we're trying to avoid?

Then again, the obvious way to actually trigger this is insanity like

float4 main() : sv_target
{
    float x[3] = {0, 2, 3};
    return x[x[1] = 1];
}

which actually *does* yield 1.

But it still makes me nervous. I'm not sure if there are other ways that this might do the wrong thing.