On 28/08/2026 20:33, Robin Dapp wrote:
Hi Alfie,
Another basic and possibly stupid question.
I struggle to believe either is possible when it comes to the vectorizer.
Initially I asked whether a length-based approach would make sense for
aarch64 as well. Not really in the sense of re-using len masking
but rather treating the number of actually read bytes as a length from
which a mask can be built.
As I'm a bit confused by all the masks being passed around and unpacked:
How bad would it be to build the mask via WHILE_ULT from the result of
COND_COUNT_ACTIVE (if that's possible)? I guess that involves a costly
vector -> GPR -> vector roundtrip but only in the fixup block that's
cold anyway.
It would be possible, but it would be costly. aarch64 would likely end
up doing the while lo once, and then unpacking it to make the other
masks as that is cheaper for aarch64 (hence the reason this code was
previously here at all). Which is essentially what this already does
without the scalar diversion.
For len based masks I was envisioning we would have two code paths in
the fixup logic creation, similar to the logic for creating the loop
controls.
I figure the len masks would treat the HSSR state as a length rather
than a mask, as you seem to want as well, and I think thats fairly
unavoidable?
Probably that's already the answer but I still wanted to
make sure (because that would allow us to avoid quite a bit of
implementation complexity).
I don't think we would lose much implementation complexity if I'm
honest. I think it would make more sense for len based loops, but mask
based loops would end up trying to undo most of it to get back to this
control, which sounds difficult to do. So I think it makes more sense to
have two control paths for the different types of loop control here.
Happy to be convinced otherwise if I've misunderstood you?
