@camelcdr IMO where you place the vector config handling in the pipeline really depends on what performance characteristics you're looking for. Handling it after scalar rename adds latency in the common case, but gets rid of a bunch of complexity that can result in really bad issues in the uncommon cases.
The way the ISA is designed certainly favors the higher-latency designs, but IMO the right decision depends on what sort of workload characteristics you're expecting to see. Unfortunately it's a hard tradeoff to make: the latency-sensitive workloads also tend to be the irregular ones that are harder to cover pre-silicon, so the chance of missing an edge case that destroys performance is high.
So designers are sort of forced to decide between rolling the dice on the lower-latency implementation or sticking with the higher-latency implementation and accepting the inherent performance penalties on some workloads.
I suspect we're going to see two very different styles of RVV implementation show up over the next few years as vendors optimize for one style or the other, and then various ISA changes go through that work around the issues in each.
The way the ISA is designed certainly favors the higher-latency designs, but IMO the right decision depends on what sort of workload characteristics you're expecting to see. Unfortunately it's a hard tradeoff to make: the latency-sensitive workloads also tend to be the irregular ones that are harder to cover pre-silicon, so the chance of missing an edge case that destroys performance is high.
So designers are sort of forced to decide between rolling the dice on the lower-latency implementation or sticking with the higher-latency implementation and accepting the inherent performance penalties on some workloads.
I suspect we're going to see two very different styles of RVV implementation show up over the next few years as vendors optimize for one style or the other, and then various ISA changes go through that work around the issues in each.