> 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. -- Regards Robin
