That sounds like a refactor from hell... I mean, maybe it's okay. But it'd be quite a bit of work. What did you have in mind?

OpCooperativeMatrixPerElementOpNV takes a variable number of sources, and passes them to a function as extra sources. I'm pondering a new instr type vs enhancing the current intrinsic? vs making 10 variants of the intrinsic (and hoping)

intrinsic("cmat_per_element_0", src_comp=[-1, -1, -1])
intrinsic("cmat_per_element_1", src_comp=[-1, -1, -1, -1])
intrinsic("cmat_per_element_2", src_comp=[-1, -1, -1, -1, -1])
intrinsic("cmat_per_element_3", src_comp=[-1, -1, -1, -1, -1, -1])

I kinda over l wonder if that shouldn't be a juiced call instruction instead. But really, there's nothing in NIR at all like this.

Okay, but what if instead of a call, the call op had the semantics of doing an argument bind and returning a closure that then gets passed to another op...

I'm not saying this is a good idea. I'm just thinking out loud here.

actually this might not be a bad idea, I'll play around with it a bit once I get my hacky 0/1/2 to pass some tests!