> The reason I went with this keeping alignment strategy is I was worried that > when processing non-VL increments, then any invariants may become unaligned > with the current iteration, possibly requiring invariants to be rotated in > the FFR fixup blocks? > > But I will need to look more into whether that is actually an issue. > Maybe you know from SELECT_VL work? I was thinking it may not be an > issue for SELECT_VL as that only uses non-VL iterations at the end of > the loop but not sure on the details?
While we pretend that every iteration's VL can be variable, it actually cannot. The problem is that it can vary (according to the spec at least) in the last two iterations, not just in the last one and that's how the whole "always dynamic length" story came about. We could fix that on a per-implementation level but haven't so far. The idea is that hardware could "load balance" the last two iterations from e.g. one iteration of 512 elements and one with 1 element to 257 and 256. I have never seen this happen in the wild (hence haven't seen any performance impact from that theoretical possibility). Similar to Richard's point, my understanding (hope?) is that the hardware only "reduces the length" at reasonable points, like on page boundaries. In that case we'd rather benefit from not keeping the initial alignment but resume from where the FF load tells us. -- Regards Robin
