Hi,
the patch has already been accepted, but since this discussion also concerns more long term work...
On 18/11/21 18:19, Zebediah Figura (she/her) wrote:
What I'm getting at is this kind of half one thing, half the opposite is bad. I think we should move towards eventually making struct sm4_instruction a proper IR and every time there is a chance of making progress in that direction we should take it.
I don't think I see why this is half of anything. We have to translate between the hlsl_ir representation of swizzles and the DXBC representation of swizzles somewhere, why not here?
Agreed, neither I can see what would be the two half things. As I see it, write_sm4_instruction is basically a serialization function, which is useful as it is and shouldn't do anything else than serialization, and struct sm4_instruction is just a way to provide structured input to write_sm4_instruction. I find it logical that all processing is done before data is fed to write_sm4_instruction, so processing and serialization are well separated.
I think it might make sense to have another optimization framework which is lower level than IR, but this should happen before write_sm4_instruction and be essentially independent of it. It might reuse struct sm4_instruction, possibly with some changes to make it easier to manipulate (like, for example, store it in a linked list).
If this were to happen, my guess is that it would make sense to have this pass at an actual lower level than our current IR, therefore drop out knowledge of the IR variables and temporaries, implying that we store the "actual" writemasks and swizzles, not those that make sense given the IR variables and temporaries. But this can only be evaluated once some actual optimization pass is there.
Just my two cents!
Giovanni.