Closed Bug 1415453 Opened 2 years ago Closed 2 years ago

Use vfpv3-d16 as default on Android/arm

Categories

(Firefox Build System :: General, enhancement)

Unspecified
Android
enhancement
Not set

Tracking

(firefox58 fixed)

RESOLVED FIXED
mozilla58
Tracking Status
firefox58 --- fixed

People

(Reporter: m_kato, Assigned: m_kato)

Details

Attachments

(1 file)

Actually we use -fpu=vfp as Android/arm default,  but I check default build option of Anroid/armeabi-v7a, it uses vfpv3-d16 instead.   So we should use it.
(Rust compiler uses -fpu=vfpv3-d16 as default of armv7-android)
Attachment #8927222 - Flags: review?(core-build-config-reviews) → review?(nfroyd)
Comment on attachment 8927222 [details]
Bug 1415453 - Use vfpv3-d16 as default on Android/arm.

https://reviewboard.mozilla.org/r/198510/#review203782

The official documentation says that we ought to be able to use this, but what about our population in the wild?  Given that Rust uses that setting and we haven't seen problems in the wild with that (?), I am a little more confident, but do you know if the Rust code that we've sent out to real devices actually contains much floating-point code?

I see that we unconditionally enable neon code for our ARMv7 devices, and IIUC, having neon implies vfpv3 (and maybe vfpv3-d16?), at least.  I see that GCC, when optimizing for a "generic v7a" cpu, enables vfpv3-d16 by default.  So I *think* this is safe.
Attachment #8927222 - Flags: review?(nfroyd) → review+
(In reply to Nathan Froyd [:froydnj] from comment #3)
> Comment on attachment 8927222 [details]
> Bug 1415453 - Use vfpv3-d16 as default on Android/arm.
> 
> https://reviewboard.mozilla.org/r/198510/#review203782
> 
> The official documentation says that we ought to be able to use this, but
> what about our population in the wild?  Given that Rust uses that setting
> and we haven't seen problems in the wild with that (?), I am a little more
> confident, but do you know if the Rust code that we've sent out to real
> devices actually contains much floating-point code?
> 
> I see that we unconditionally enable neon code for our ARMv7 devices, and
> IIUC, having neon implies vfpv3 (and maybe vfpv3-d16?), at least.  I see
> that GCC, when optimizing for a "generic v7a" cpu, enables vfpv3-d16 by
> default.  So I *think* this is safe.

Android's NDK tools uses vfpv3-d16 as default options, so rust compiler uses this.  And all armv7 devices of Android have hard float.  You know, a few devices that uses Tegra-2 doesn't have neon.

Also, we don't support non-neon device now, but we shouldn't build mozglue using neon because mozglue has a function to detect neon or not for JNI.
Pushed by m_kato@ga2.so-net.ne.jp:
https://hg.mozilla.org/integration/autoland/rev/d8626c12e13f
Use vfpv3-d16 as default on Android/arm. r=froydnj
https://hg.mozilla.org/mozilla-central/rev/d8626c12e13f
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.