On 5/24/24 11:14 AM, Palmer Dabbelt wrote:
On Fri, 24 May 2024 09:19:09 PDT (-0700), Robin Dapp wrote:
We should have something in doc/invoke too, this one is going to be
tricky for users.  We'll also have to define how this interacts with
the existing -mstrict-align.

Addressed the rest in the attached v2 which also fixes tests.
I'm really not sure about -mstrict-align.  I would have hoped that using
-mstrict-align we'd never run into any movmisalign situation but that
might be wishful thinking.  Do we need to specify an
interaction, though?  For now the new options disables movmisalign so
if we hit that despite -mstrict-align we'd still not vectorize it.

I think we just need to write it down.  I think there's two ways to encode this: either we treat scalar and vector as independent, or we couple them.  If we treat them independently then we end up with four cases, it's not clear if they're all interesting.  IIUC with this patch we'd be able to encode
Given the ISA documents them as independent, I think we should follow suit and allow them to vary independently.


* -mstrict-align: Both scalar and vector misaligned accesses are  unsupported (-mrvv-allow-misalign doesn't matter).  I'm not sure if  there's hardware there, but given we have systems that don't support  scalar misaligned accesses it seems reasonable to assume they'll also  not support vector misaligned accesses. * -mno-strict-align -mno-rvv-allow-misalign: Scalar misaligned are  supported, vector misaligned aren't supported.  This matches our best  theory of how the k230 and k1 behave, so it also seems reasonable to  support. * -mno-strict-align -mrvv-allow-misalign: Both scalar and vector  misaligned accesses are supported.  This seems reasonable to support  as it's how I'd hope big cores end up being designed, though again  there's no hardware.
I'd almost lean towards -m[no-]scalar-strict-align and -m[no-]vector-strict-align and deprecate -mstrict-align (aliasing it to the scalar alignment option). But I'll go with consensus here.


The fourth case is kind of wacky: scalar misaligned is unsupported, vector misaligned is supported.  I'm not really sure why we'd end up with a system like that, but HW vendors do wacky things so it's kind of hard to predict.
I've worked on one of these :-) The thinking from the designers was unaligned scalar access just wasn't that important, particularly with mem* and str* using the vector rather than scalar ops.

jeff



Reply via email to