android-riscv64
android-riscv64 copied to clipboard
google
CTS: add misaligned load/store tests for scalar and vector
we (via bionic) already test that __riscv_hwprobe() claims fast misaligned accesses, but https://github.com/llvm/llvm-project/issues/88029 is a case where hardware [correctly] claims fast misaligned accesses ... but mutters "scalar" under its breath while doing so. and doesn't just have slow misaligned vector loads/stores, it SIGBUSes.
we should probably have CTS tests that check that misaligned loads and stores work, for both scalar and vector.
(we also need to make sure that some verbiage to this effect makes it into the published Android/riscv64 ABI, but i've added a note about that to the internal doc, and don't think we need an explicit bug here.)
With https://github.com/llvm/llvm-project/pull/88954/files clang explicitly passes +unaligned-scalar-mem +unaligned-vector-mem to the llvm backend.
Do we need to refine the hwprobe interface to have fast vector misaligned vs fast scalar misaligned?
Do we need to refine the hwprobe interface to have fast vector misaligned vs fast scalar misaligned?
"you add it, i'll call it in Android's CTS tests" :-)
Will it be a good idea to add repro tests from https://github.com/llvm/llvm-project/issues/88029, https://godbolt.org/z/ETaKqTTPc in CTS?
Will it be a good idea to add repro tests from llvm/llvm-project#88029, https://godbolt.org/z/ETaKqTTPc in CTS?
yes, i think so. i'd definitely +2 that. feel free to stick it in bionic/tests/sys_hwprobe_test.cpp for now, for want of a better place. i think we'll have quite a lot of these "let's clarify exactly what we mean and check that the kernel's telling the truth" kinds of tests, and -- given that latter bit -- it doesn't seem unreasonable to have them in with the hwprobe tests?
Added in bionic https://android-review.googlesource.com/c/platform/bionic/+/3063184