I think you missed my point. As shown when you contradicted yourself:
me: What if they have a function that uses a pointer already?
you: That function should be changed to return a struct and would then get inlined
me: What if they just do their job and write their translator to handle it?
you: w00t one guy did his job correctly, now for all the other implementations
That could just as easily be aimed at the previous case: everyone who’s back-end works a certain way must change it. Thus putting “pressure on the optimizers”, rather than anyone else.
My overall point is that the current state of things only “puts pressure on the optimizers” for systems who’s back-ends work a certain way. If the back-end happens to work SPIR-V’s way, then there’s no pressure at all. Therefore, your suggestion is only reasonable if you have knowledge that back-ends are more likely to work your way than SPIR-V’s way.
So please present said evidence.
Equally importantly, this “pressure on the optimizers” must already exist. Why? Because any decently implemented back-end must accept the very real possibility that the user will want to pass return values back via pointers rather than through returning structs. Maybe it’s an in/out value. Or whatever. It’s the user’s prerogative, and therefore, it’s the optimizer’s job to optimize that.
And if it can handle it in the function case, there’s on reason why it can’t in the opcode case. Since this work must already be done… there’s no point in changing this here.