Open Bug 1447577 Opened 6 years ago Updated 5 months ago

Drop support for ARMv6

Categories

(Core :: JavaScript Engine: JIT, enhancement, P3)

Product:
Core
Component:
JavaScript Engine: JIT
Type:
enhancement

Tracking

()

People

(Reporter: jandem, Unassigned)

References

Details

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
Flags: needinfo?(jdemooij)
SupportsUnalignedAccesses returns true on ARM iff we're on ARMv7 [0]. 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.

[0] https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/js/src/jit/arm/Assembler-arm.h#1769
Flags: needinfo?(jdemooij)
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?
Flags: needinfo?(bbouvier)
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?)
Flags: needinfo?(bbouvier)
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.
Priority: -- → P3
Severity: normal → S3

I am adding a reference to https://bugzilla.mozilla.org/show_bug.cgi?id=1814637

Is ARMv6 with hard-float still supported? According to @RyanVM the support has been dropped 5 years ago. If so please close this bug and document it somewhere, as a user of Raspberry Pi Zero it's difficult to find the state of affairs. References:

Flags: needinfo?(ryanvm)

Note that this bug is specifically about the Spidermonkey JS engine, not Firefox on the whole. It's entirely possible for Spidermonkey to support architectures which aren't officially supported for Firefox. We have a policy specifically outlining Firefox platform support shown below.
https://firefox-source-docs.mozilla.org/contributing/build/supported.html

Mozilla never shipped official binaries for armv6 on Raspberry Pi and they would fall under Tier 3 in the above doc. I'm sorry if this is difficult to navigate, but ultimately your questions regarding what builds of Firefox can run on your specific Raspberry Pi device would be a question for the maintainers of those builds.

Flags: needinfo?(ryanvm)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)

Note that this bug is specifically about the Spidermonkey JS engine, not Firefox on the whole. It's entirely possible for Spidermonkey to support architectures which aren't officially supported for Firefox.

Agreed. That said, our ARMv6 support is not tested by Firefox users anymore so I don't know how reliable it still is. It probably makes sense for us to drop support in the JIT backend, but that work still has to happen so we should keep this open.

Note that this bug is specifically about the Spidermonkey JS engine, not Firefox on the whole. It's entirely possible for Spidermonkey to support architectures which aren't officially supported for Firefox.

Yes, I asked here specifically to get information about spidermonkey. If spidermonkey does not support ARMv6 at all, then I shouldn't spend time trying to optimise a Firefox build.

Mozilla never shipped official binaries for armv6 on Raspberry Pi

Yes, I'm mostly interested in debugging the slowness of custom builds of Firefox. Asking here to figure out general support status is one thing. Another is that I filed bug 1825159 for figuring this out in about:support. Otherwise I see no indication of JIT-compilation enabled, other than running benchmarks on every build and hoping it goes faster.

Anyway, I think I what [:jandem] mentioned is useful i.e. it's supported but untested.

You need to log in before you can comment on or make changes to this bug.