[PATCH 2/2] riscv: vectorised mem* and str* functions

[Andrew Waterman]

On Thu, Feb 2, 2023 at 4:13 PM Vineet Gupta <vineetg@rivosinc.com> wrote:
>
>
>
> On 2/1/23 11:03, Andrew Waterman wrote:
> >> +#ifndef __riscv_strict_align
> > strict-align is not the right thing to check here.  As the RVA profile
> > document explains, all RVA-compliant implementations must support
> > misaligned loads and stores (so strict-align will be false), but they
> > might execute extremely slowly (e.g., via trap and emulate), and so
> > this approach will unduly penalize some implementations.
>
> FWIW, the proposed __riscv_strict_align if generated can have 2 possible
> values:
>   - 1 (explicit -mstrict-align used in build)
>   - 2 cpu tune param indicated unaligned access is slow (like with
> trap-n-emulate)

Yeah, those semantics make sense.  It makes the "strict" name a little
misleading, though: "strict" suggests to me that misaligned accesses
are outright illegal.  So, it might be better to pick another name,
e.g. __riscv_avoid_misaligned.

>
> So if theory code can still be written to cater to that.

It had better cater to it in practice as well as in theory.  Standard
binary distributions need to be suitably generic, and they need to
heed the guidance in the RVA profile spec.  So this is OK as long as
the default continues to be to avoid misaligned accesses.  The fact
that GCC's default -mtune setting is to mark them as slow means this
is probably OK.

This may be Yet Another IFUNC Case: use misaligned accesses only if
known at runtime that they are fast, or when there's a routine
available that's optimized for a specific microarchitecture.
(Microarchitecture-specific IFUNCs would probably be more appropriate
for these routines, anyway, since they're pretty clearly tuned for a
particular machine.  For example, the trivial 7-instruction memcpy
loop recommended in the specification will perform well across a
broader range of vector machines.)

>
> -Vineet