RISCV `-mno-strict-align` generates problem instructions for some targets

[sh1boot]

When passed --target=riscv64-linux-gnu -march=rv64gcv -mno-strict-align, clang-18 and up generate vle64 and vse64 instructions for the following code despite receiving byte pointers:

__attribute__((noinline))
void vector_memcpy(uint8_t* d, uint8_t const* p) {
  __builtin_memcpy(d, p, 16);
}

https://godbolt.org/z/eb4oqM3Ts

If the pointer is unaligned then my Kendryte K230 board (C908) will raise a bus error trying to execute this.

However, -mno-strict-align offers big performance gains for some scalar code, where unaligned access is supported just fine. There seems to be no way to specify that vector code should respect alignments while scalar code can do unaligned access.

Scalar code "seems to work" when you cast a byte pointer to a wider type when it's unaligned, but there are other issues with that and most portable code prefers memcpy() with the expectation that the compiler will optimise it correctly.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: S H (sh1boot)

When passed ` --target=riscv64-linux-gnu -march=rv64gcv -mno-strict-align`, clang-18 and up generate `vle64` and `vse64` instructions for the following code despite receiving byte pointers:

__attribute__((noinline))
void vector_memcpy(uint8_t* d, uint8_t const* p) {
  __builtin_memcpy(d, p, 16);
}

https://godbolt.org/z/eb4oqM3Ts

If the pointer is unaligned then my Kendryte K230 board (C908) will raise a bus error trying to execute this.

However, -mno-strict-align offers big performance gains for some scalar code, where unaligned access is supported just fine. There seems to be no way to specify that vector code should respect alignments while scalar code can do unaligned access.

Scalar code "seems to work" when you cast a byte pointer to a wider type when it's unaligned, but there are other issues with that and most portable code prefers memcpy() with the expectation that the compiler will optimise it correctly.

[topperc]

Is unaligned scalar really supported in hardware on C908, or is it emulated via a trap and the trap handler doesn't know how to emulate vector?

[sh1boot]

Unaligned scalar loads definitely make my test code run much faster on C908. If it is emulated then it's emulated so efficiently that it's still better than using extra application code to avoid un-aligned loads.

[wangpc-pp]

Is it the case that unaligned scalar is supported while unaligned vector is not supported?
#73971 cc @preames
I don't remember the details, maybe t-head guys can help to answer this. @zixuan-wu @rjiejie

[sh1boot]

Well on the k230 SOC, unaligned scalar memory access does work and does not have a significant performance impact. It is much faster than loading bytes and assembling them into a word in application code. Enabling this optimisation has a big impact on performance.

Meanwhile, vle8 works at arbitrary memory offsets, and vle64 raises a bus error if given an odd memory address.

Is it supposed to be configurable in the kernel? I don't know. Somebody is shipping kernels configured this way anyway.

Clang-17 currently generates much faster code than clang-18 and clang-19 because the latter cannot emit unaligned scalar access safely.

[appujee]

For llvm, we should have a way to differentiate fast unaligned access support for both scalars and vectors. The current -mno-strict-align is confusing and resulting in bug like this. See google/android-riscv64 for the context.

[asb]

Just summarising my understanding of things so people can point out if I have it wrong or disagree:

• Zicclsm was defined is a mandatory extension in the RVA20 profile and is explicitly specified as indicating support for misaligned load/store for both scalar and vector memory operations. They might execute slowly of course.
  • While the success of RISC-V profiles remains to be seen, I think it's fair to consider that an application that subsets RVA20 is going to be fairly niche going forwards. We should moderate our effort in terms of defining compiler flags etc based on this.
• Separately there's the issue of whether those loads/stores are fast or not. There was quite a lot of back and forth on this here [RFC] Preprocessor definition to specify data alignment strict(ness) riscv-non-isa/riscv-c-api-doc#32 (which also documented the recommendation that the compiler maps -mno-strict-align as meaning unaligned access is fast) that but it looks like we never really considered the answer being different for vector vs scalar.

It would be useful to know if there is other hardware where scalar misaligned access are fast, but vector slow. If it's basically unheard of, that might indicate different solutions in terms of command-line interface vs if it's likely to happen quite a lot. In the latter case, perhaps we got the interface for riscv-non-isa/riscv-c-api-doc#32 wrong.

[appujee]

Zicclsm was defined is a mandatory extension in the RVA20 profile and is explicitly specified as indicating support for misaligned load/store for both scalar and vector memory operations.

Makes sense to not have compiler flags as the misaligned access support for both scalar and vectors is clearly required for the RVA20 profile. Thanks for pointing to the reference.

[sh1boot]

I believe I tried Zicclsm as part of -march when I was trying to figure out how to enable unaligned codegen (noting problems with uneven handling of -mno-strict-align), and it didn't help; but since I want sure I understood the description I didn't raise a bug.

If that is the same thing then I guess C908 might be considered an RVA20 compliant device if something emulated (or enabled) unaligned vector memory ops by default?

But I think RVA20 isn't telling us if the operation is fast enough to use, right? Just that it shouldn't give a bus error. That's what the command line argument would be for iff C908 became a device that met the required spec or if there were others like it?

[MaoHan001]

I believe I tried Zicclsm as part of -march when I was trying to figure out how to enable unaligned codegen (noting problems with uneven handling of -mno-strict-align), and it didn't help; but since I want sure I understood the description I didn't raise a bug.

If that is the same thing then I guess C908 might be considered an RVA20 compliant device if something emulated (or enabled) unaligned vector memory ops by default?

But I think RVA20 isn't telling us if the operation is fast enough to use, right? Just that it shouldn't give a bus error. That's what the command line argument would be for iff C908 became a device that met the required spec or if there were others like it?

C908 supports general unaligned access for vectors, but not element unaligned access in vectors, which should comply with the relevant spec requirements:
https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#8-vector-memory-alignment-constraints
Therefore, in our optimizations for memory load/store, we generally handle unaligned logic using elements of length 8, and larger elements are employed when aligned.
Referring to arch/riscv/kernel/traps_misaligned.c, the kernel we are currently using does not seem to handle unaligned vectors.
https://gitee.com/thead-yocto/kernel/blob/master/arch/riscv/kernel/traps_misaligned.c#L240
Based on my impression that vector misalignment is purely handled by hardware, and its performance should be faster compared to regular instructions.

[lukel97]

Is it the case that unaligned scalar is supported while unaligned vector is not supported? #73971 cc @preames I don't remember the details, maybe t-head guys can help to answer this. @zixuan-wu @rjiejie

Before #73971 -mno-unaligned-access enabled both unaligned scalar and vector accesses anyway, so that was just an internal-facing change