On 9/20/22 09:43, Francisco Casas wrote:
In the future we would probably want to remove the "offset" field from the derefs, and make each hlsl_sm*.c compute the register offsets from the derefs in their index path form.
We definitely want to get rid of "offset" from the derefs.
Regarding this, after some thought I am actually not sure. Consider a complex non-constant offset dereference such as 'foo[n][m]' in:
unsigned int n, m;
float4 main() : sv_target { float4 foo[3][4] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11};
return foo[n][m]; }
So far I haven't seen these being represented with a complex expression within the index of an instruction's register (I doubt that register indexes can be more complex than a reference to another register plus a constant offset).
Instead, a single temporal register is created and then referenced (r0 in this case):
ishl r0.x, cb0[0].x, l(2) iadd r0.x, r0.x, cb0[0].y mov r0.x, x0[r0.x + 0].x mov o0.xyzw, r0.xxxx
So it is reasonable for me to keep the deref offset instruction to serve this purpose.
I suggest we review this again after once I send this patch series as a merge request.
Well, when generating sm1 or sm4 IR we are going to need to be able to construct arbitrarily complex offsets, possibly involving new registers. In a sense we're going to have to generate the multiplication and addition instructions at translation time, instead of earlier as now. In essence I expect write_sm4_load() to generate almost exactly those instructions (modulo ishl vs imul or copy-prop optimizations...)