See bug 1440733. This lets us simplify the ARM backend because we can assume features like MOVW/MOVT are always available. Firefox for Android doesn't support ARMv6 according to https://support.mozilla.org/en-US/kb/will-firefox-work-my-mobile-device
SupportsUnalignedAccesses returns true on ARM iff we're on ARMv7 . It would always return true (on all platforms) if we dropped ARMv6 support so we could remove SupportsUnalignedAccesses. Last week Lars mentioned this is actually not guaranteed to be the case on all ARMv7 devices and there's another flag we should be checking. Considering we're not aware of any issues in the wild maybe it's okay to assume this is true, though.  https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/js/src/jit/arm/Assembler-arm.h#1769
So the story on ARMv7 is described in the ARMv7 reference manual section 3.2.1. ARMv7 must "support" unaligned access, but this probably means that (a) it can't silently chop data a la ARMv5 and (b) it must support the control word bit that controls alignment. The bit in the control word is known as SCTRL.A. If it is 1, all unaligned accesses fault. If it is 0, some unaligned accesses do not trap but are performed normally. The ones for which unaligned accesses are handled are halfword and word nonexclusive integer loads and stores including /some/ variants of push and pop, and FP vector loads and stores with standard alignment. Exclusive loads and stores, doubleword loads and stores, /other/ variants of push and pop, multi-word loads and stores, single-item FP loads and stores, and vector loads and stores with non-standard alignment specifiers trap. Now on Linux, there's another flag that controls the behavior if SCTRL.A says to trap... The story is here, https://www.kernel.org/doc/Documentation/arm/mem_alignment. I'm not sure how much it matters. I did look at some ARM systems once to see what their settings were, I believe the two that I had access to were both set to 1 ("kernel fixup"). Incidentally SCTRL.A is not readable from user-space (ARMv7 RM B4.1.130). My take on this is that on phones we would expect to see direct support for unaligned accesses (but only for some instructions, not nearly for all) and for the kernel to fixup the rest, because this is sane for consumer devices running mass-market software. On other ARM systems I have no idea what to expect. FWIW, ARMv8 generalizes the above policies so that only exclusive-access instructions don't support unaligned access; all the others are controlled by the flag in the control word. It is *probably* safe to remove the flag, and it would slightly simplify code on ARM (and we would not have to write some code that is now not written). We do run the risk of obscure performance problems on some platforms, where the kernel fixes up accesses that were properly flagged as unaligned in the wasm code. Benjamin, opinions?
Last time I've tried, a recent Android device had the kernel mem_alignment set to 1 (fixup) too. My olde raspberry pi 2 doesn't have it, but it's also ARMv6, which is becoming more and more rare. In general, ARMv6 is becoming very rare: last time we've discussed this in an internal email thread with internal numbers, we concluded that < 0.1% of users (absolute value < a thousand) were using ARMv6, from two different sources of data. The initial plan has been to throw an Error when an unaligned access showed up, and expect people to complain about it if this were a problem. In hindsight, this plan was terrible, because: 1. most users don't come back to us to complain, 2. most wasm programs are compiled from large code bases which would also exhibit the same issues when natively compiled to mobile devices. What we could easily do now is to set a use counter every time we see such an error. Not really needed if we just decide to drop ARMv6, in which case I'd like to confirm first that the kernel fixup actually works also for unaligned floating-point accesses. (I seem to recall it did not, but that's been a while) If all kind of accesses are silently fixed up, then I'm all in for removing signal handling of unaligned accesses, and ARMv6 too. (random question: does MIPS generate a SIGBUS on unaligned accesses, and if so, how much do we care?)
ARMv6 is dead so we should not keep the flag for that reason. But if any in-tree architecture requires this flag then we just have to keep it, even if tier-3. I don't know what MIPS does but a SIGBUS sounds likely. Whether that error is fixup-able, and whether the kernels do fix it, I don't know. I don't necessarily agree that "most wasm programs are compiled from large code bases which would also exhibit the same issues when natively compiled to mobile devices", because when compiling a codebase for ARM you select struct and variable alignment that is appropriate for ARM, but when you compile for wasm you might (inadvertently or unknowingly) select alignment that is appropriate for, say, x86 but not for ARM. Also you might not ever have compiled it for ARM to begin with, and wouldn't - all you care about is wasm. Of course all that's speculation. The issue about unaligned FP is interesting. My memory is like yours - you reported that fixups did not work properly. All of this is OS-dependent, of course. Windows 10 on ARM is a thing, even if we don't have a product there yet. And there are some old Linux kernels out there, supporting Android.
You need to log in before you can comment on or make changes to this bug.