@camelcdr yes, right, I wasn't looking closely enough at the actual op.
I guess I was thinking of that as a different issue: that's sort of the long-decoder issue, where you have to decide how well the implementation is going to handle instructions that generate more uops than it can deal with in a group (which may or may not be equal to your rename bandwidth). That's what I've seen be the issue with long-LMUL performance, and that doesn't change when you move around the V rename point. Renaming V later just lets you know what the actual uop requirement is without predicting.
and FWIW: it's definitely possible to decouple the rename granularity from the architectural register size. I agree it's probably not a good idea ;)
I guess I was thinking of that as a different issue: that's sort of the long-decoder issue, where you have to decide how well the implementation is going to handle instructions that generate more uops than it can deal with in a group (which may or may not be equal to your rename bandwidth). That's what I've seen be the issue with long-LMUL performance, and that doesn't change when you move around the V rename point. Renaming V later just lets you know what the actual uop requirement is without predicting.
and FWIW: it's definitely possible to decouple the rename granularity from the architectural register size. I agree it's probably not a good idea ;)