On 5/28/24 1:19 PM, Robin Dapp wrote:
Hi,
this patch disables movmisalign by default and introduces
the -mno-vector-strict-align option to override it and re-enable
movmisalign. For now, generic-ooo is the only uarch that supports
misaligned vector access.
The patch also adds a check_effective_target_riscv_v_misalign_ok to
the testsuite which enables or disables the vector misalignment tests
depending on whether the target under test can execute a misaligned
vle32.
Changes from v3:
- Adressed Kito's comments.
- Made -mscalar-strict-align a real alias.
Regards
Robin
gcc/ChangeLog:
* config/riscv/riscv-opts.h (TARGET_VECTOR_MISALIGN_SUPPORTED):
Move from here...
* config/riscv/riscv.h (TARGET_VECTOR_MISALIGN_SUPPORTED):
...to here and map to riscv_vector_unaligned_access_p.
* config/riscv/riscv.opt: Add -mvector-strict-align.
* config/riscv/riscv.cc (struct riscv_tune_param): Add
vector_unaligned_access.
(riscv_override_options_internal): Set
riscv_vector_unaligned_access_p.
* doc/invoke.texi: Document -mvector-strict-align.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add
check_effective_target_riscv_v_misalign_ok.
* gcc.dg/vect/costmodel/riscv/rvv/dynamic-lmul2-7.c: Add
-mno-vector-strict-align.
* gcc.dg/vect/costmodel/riscv/rvv/vla_vs_vls-10.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/vla_vs_vls-11.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/vla_vs_vls-12.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/vla_vs_vls-8.c: Ditto.
* gcc.dg/vect/costmodel/riscv/rvv/vla_vs_vls-9.c: Ditto.
* gcc.target/riscv/rvv/autovec/vls/misalign-1.c: Ditto.
So per the patchwork discussion this morning let's go ahead with this,
knowing we may need to revisit for:
1. Coordination with LLVM on option naming/behavior. LLVM will have a
release before gcc-15, so if at all possible we should follow their lead
on option naming.
2. Adjusting defaults once kernel unaligned trap handlers are in place.
Palmer is going to reach out to David on his team to tray and push
things towards using generic-ooo tuning for Fedora on RISC-V. I'll do
the same with Ventana's contacts at Canonical (Heinrich & Gordon).
I expect we're better aligned with Fedora on this topic -- Fedora feeds
RHEL which isn't likely to care about SBCs, so cores that Fedora is
going to be the most interested in over time are much more likely to
handle unaligned vector loads/stores in hardware. So the path we want
lines up with Fedora quite well, IMHO.
Canonical seems to be more interested in supporting these SBCs, so they
may have a harder time with a default to ooo-generic since it'll either
result in binaries that don't work (today) or have poor performance
(future with kernel trap unaligned trap handlers updated).
Jeff
