On ARM, the VLDR and VSTR instructions can't handle unaligned
accesses, instead they will generally trap with a SIGBUS. Some time
ago I added code to handle the trap and emulate the instructions in
the trap handler. This emulation is brittle in the sense that it
depends on information about kernel data structures, and that
information is not always available. So we need to handle this
differently, as follows.
This patch removes the SIGBUS handling and the load/store emulation,
and instead uses other instructions than VLDR/VSTR to handle FP loads
On NEON-equipped systems (on almost all ARMv7 systems and on all ARMv8
systems), use the NEON VLD1 and VST1 instructions - they can deal with
unaligned data just fine.
On non-NEON-equipped systems, use a fallback path via integer load and
store, moving integer data to and from the FP register file.
Both paths depend on us seeing no unaligned traps, ie, either
SCTRL.A=0, or the kernel handling alignment traps when SCTRL.A=1. But
we've long since assumed that unaligned integer loads and stores will
Just Work under exactly those conditions, so this is going to have to
count as good enough. (And it's what V8 did, last I looked.)
As our assembler, simulator, and disassembler don't currently support
NEON much at all, I've had to add various support for VLD1/VST1, both
new variants and a drive-by fix to an existing VLD1 variant that
didn't handle wasm traps.
For code that does not use unaligned FP accesses, the performance of
the new NEON code should be the same as the old code, while the new
non-NEON code might be a hair slower (this is OK since almost all
systems have NEON). For code that does use unaligned FP accesses,
performance should be much better, as we avoid the signal handler.
Depends on D121832