On Fri, 24 May 2024 16:31:48 PDT (-0700), jeffreya...@gmail.com wrote:
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.
I'm only reading Zicclsm as saying both scalar and vector misaligned
accesses are supported, but nothing about the performance.
* -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.
Seems reasonable to me. Just having a regular naming scheme for the
scalar/vector makes it clear what we're doing, and it's not like having
the extra name for -mscalar-strict-align really costs anything.
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.
OK then ;)
