After thinking about this for a while, and grabbing some ideas from when we discussed this issue, I think that we should split `HLSL_IR_LOAD` into two:
- `HLSL_IR_LOAD`: represents a load from a variable to a temp, cannot be used as an lhs.
- `HLSL_IR_REFERENCE`: Merely contains a deref to a variable (or a part of it) but doesn't have an SSA value and cannot be used as a source.
Well, it'd have to have an SSA value. E.g. you can have expressions like "x[1].xyzw".
HLSL_IR_REFERENCE isn't a bad name, I'll also throw out HLSL_IR_INDEX [to match e.g. hlsl_new_load_index().]
So, while parsing we always work with an `HLSL_IR_REFERENCE`, until a value is required (for instance, as part of an expression), in which case, an `HLSL_IR_LOAD` has to be created from the `HLSL_IR_REFERENCE` (basically just copying the deref).
I'd just do them all at once in a pass immediately after parsing; that way you don't have to worry about different instruction types.
`HLSL_IR_REFERENCE` would probably also need an additional field with resource locations for creating `HLSL_IR_RESOURCE_LOAD` and `HLSL_IR_RESOURCE_STORE`, when a Texture or UAV is indexed. This could also be the solution for SM 5.1 resource arrays.
Wait, why?