1501542 - Implement CheckARMSupport for Android

Status: RESOLVED FIXED

(NSS :: Libraries, enhancement, P1)

Description

[Makoto Kato [:m_kato]]

Android 18+ (4.3+) has getauxval function, so we should use it when this function is available even if Android.

Comment 1

[Makoto Kato [:m_kato]]

Attachment: Bug 1501542 - Implement CheckARMSupport for Android. r?franziskus

Android 4.3 or later has getauxval, so we should use it to detect ARM features.

Also, current CPU detection has a bug to detect NEON.  AT_HWCAP2 doesn't return
NEON bit.

Comment 2

[Makoto Kato [:m_kato]]

I investigate more for sources/android/cpufeatures/cpu-features.c

Although looking cpu-features.c in sources/android/cpufeatures/cpu-features.c, some devices may return 0 by getauxval (most is that this function isn't implemented).  If this situation, cpu-features.c reads /proc/self/auxv instead.

So if getauxval returns non-zero value, cpu-features doesn't use this fallback in cpu-features.c.

So when getauxval returns non-zero, it is valid.  And if getauxval returns invalid value that is non-zero, cpu-features.c cannot detect valid cpu features.

Could you check sources/android/cpufeatures/cpu-features.c in NDK?

Comment 3

[Makoto Kato [:m_kato]]

So it means that NDK document says getauxval may return 0 even if some features are supported.

Comment 4

[Makoto Kato [:m_kato]]

Attachment: Bug 1501542 - Part 2. Implement CheckARMSupport for Android. r?franziskus

Android 4.3 or later has getauxval, so we can use it to detect ARM features.

Also, current CPU detection has a bug to detect NEON.  AT_HWCAP2 doesn't return
NEON bit.  So it should use AT_HWCAP instead of AT_HWCAP2.  But some old device such as Nexus 4 doesn't return valid value for getauxval(AT_HWCAP).  So we don't trust return value of AT_HWCAP on Android.

Since AT_HWCAP2 is implemented in newer devices, cpu-features in Android NDK doesn't have fallback such as AT_HWCAP case.  So we can trust it.

Also, if toolchain / system's default is NEON, compiler defines __ARM_NEON__ and/or __ARM_NEON (like x86's __SSE2__ defines), so if it is defined, we always
allow NEON.

Depends on D11430

Comment 5

[Makoto Kato [:m_kato]]

Attachment: Bug 1501542 - Part 1. Use -mfpu=neon to compile NEON code. r?franziskus

To compile ARM's NEON code, compiler may require -mfpu=neon.

Actually, since Gecko always turn on NEON (Bug 1469790), it already uses -mfpu.
But tier-3 platform such as Linux/armeabi doesn't set -mfpu=neon as default.
So it might require this command line option.

Comment 6

[J.C. Jones [:jcj] (he/him)]

Makoto Kato - Are you still planning to revise the attached patches per Franziskus' feedback? If so, note that you'll need a new reviewer. Needinfo me in that case and I'll find you one. Thanks!

Comment 7

[Makoto Kato [:m_kato]]

(In reply to J.C. Jones [:jcj] (he/him) from comment #6)

Makoto Kato - Are you still planning to revise the attached patches per Franziskus' feedback? If so, note that you'll need a new reviewer. Needinfo me in that case and I'll find you one. Thanks!

Although I set reviewer to you, who is better for ARM issue? I have a plan that I would like to add ARM specific optimization such as bug 1152625.

Comment 8

[J.C. Jones [:jcj] (he/him)]

(Note: Working on finding one!)

Comment 9

[Makoto Kato [:m_kato]]

https://treeherder.mozilla.org/#/jobs?repo=nss-try&revision=25f63eb8aafbc688d959c3413357c786b9f63512

Comment 10

[J.C. Jones [:jcj] (he/him)]

Looks like Martin is your best bet, and he's already here. Clearing my ni?

Comment 11

[Martin Thomson [:mt:]]

Now that 3.43 is out of the way, I feel more comfortable landing this. Sorry about the long delays.

https://hg.mozilla.org/projects/nss/rev/7aee8be586cbeaacfaa3f02fb1ffa1f4a91ad217
https://hg.mozilla.org/projects/nss/rev/050a12f3ef7456fc0c587809ec7ed95f15318c1e