On 23/06/2026 12:04, Robin Dapp wrote:
This patch series was already spiralling out of control a bit so I
figured I would limit it to mask based vectorisation for now (read
aarch64) and just try to keep it so we can handle other architectures
later as needed. I think most other architectures should be easier as
they seem not to have the spurious partial loads which is where most of
this complexity comes from.
Ah, by spurious you mean "not caused by an actual trap" but (like in your cover
letter) at page boundaries etc. and we just have no way of knowing when that
actually happens.
Hmm, thinking about when the riscv counterparts can reduce the length, I think
it's also not just for traps but at page boundaries etc. I'll confirm but that
was my general understanding so far:
"Even when an exception is not raised, implementations are permitted to process
fewer than vl elements and reduce vl accordingly, but if vstart=0 and vl>0,
then at least one element must be processed."
That would indicate a similar behavior as the one you're describing for
aarch64.
Ah okay, I had tried to look this up but clearly incorrectly came to the
conclusion that wasn't the case. Then this will also require some thought.
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?
