I'm going to have to push back on 2/4. Along the lines of 215, I don't want to spend too much effort doing this on the HLSL level when we really should be doing these kinds of transformations over lower level IR.
I am not following what on 2/4 requires too much effort. Can you specify?
In sm4 relative addressing can only be done with "whole-register granularity", meaning that the node has to be expressed in whole registers and to specify register components we require a constant uint offset. If the node is constant, moving its value to this constant uint is a low-hanging fruit, I think.
I don't like how 4/4 avoids the recursive struct; probably better to do it like vkd3d_shader_register.
The thing is that the `struct sm4_instruction` values are "ephemeral", they are only created to be used as an input to write_sm4_instruction() and currently they don't allocate heap memory.
I made the extended register `struct sm4_xregister` to avoid allocating heap memory and having to take it into account and free it everywhere it is used, and its `.r` field can be initialized as a regular register.
I guess you are thinking on something more orthodox, along the lines of:
```c struct sm4_register_index { struct sm4_register *rel_addr; unsigned int offset; };
struct sm4_register { enum vkd3d_sm4_register_type type; struct sm4_register_index idx[2]; unsigned int idx_count;
/* ... */ };
static struct sm4_register *sm4_new_register(void); static void sm4_register_add_index(struct sm4_register *reg, struct sm4_register *rel_addr, unsigned int offset); static void sm4_register_cleanup(struct sm4_register *reg); ```
so I am implementing that.