Skip to contentSkip to conversation

cortexa8: use hard floating point

RFC PATCH In review Darren Hart 5 participants 5 messages Aug 18, 2011 – Aug 19, 2011

lore
Share & tools
lore
#0 lore raw

RFC PATCH 1/1 cortexa8: use hard floating point

From what I could gather, it makes sense to address using mfloat-abi=hard for the beagleboard in the cortexa8 tune file. Before I submit this as a pull request, I'd appreciate a sanity check from the Beagleboard experts.

Is there any reason the cortexa8 tune file should not be using "hf" by default?

Thanks,

Darren

--------
Fixes [YOCTO #1203]

mfloat-abi is currently set to soft for beagleboard (cortexa8) and needs to be set to hard to take advantage of the floating point hardware.

Append "hf" to each of the cortexa8 TUNE_FEATURES and PACKAGE_EXTRA_ARCHS variables. This enables "callconvention-hard" from the included arch-armv7a.inc.

Add a missing closing quote to the VFP AVAILTUNES append operation.

CC Jason Kridner <[email protected]>
CC Koen Kooi <[email protected]>
---
 meta/conf/machine/include/arm/arch-armv7a.inc |    2 +-
 meta/conf/machine/include/tune-cortexa8.inc   |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)
meta/conf/machine/include/arm/arch-armv7a.inc +1 -1
index 704f86b..d508352 100644
@@ -20,7 +20,7 @@ PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a ar
 PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
 
 # VFP Tunes
-AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
+AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon"
 TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
 TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
 TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
meta/conf/machine/include/tune-cortexa8.inc +5 -5
index 02b560c..e7483b9 100644
@@ -6,11 +6,11 @@ TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
 
 AVAILTUNES += "cortexa8 cortexa8t"
-TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} cortexa8"
-TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} cortexa8"
+TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7ahf} cortexa8"
+TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7athf} cortexa8"
 TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
 
-PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
-PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
-PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon}"
 
Signature · 5 lines
1.7.1
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
#1 lore raw

Op 18 aug. 2011, om 08:16 heeft Darren Hart het volgende geschreven:

Quoted 2 lines

From what I could gather, it makes sense to address using mfloat-abi=hard for the beagleboard in the cortexa8 tune file.

It doesn't, actually. Sadly the internet is now full with posts from misinformed meego and debian people about this issue, so I see why someone might think hfp cures cancer and creates world peace.

Quoted 4 lines

Before I submit this as a pull
request, I'd appreciate a sanity check from the Beagleboard experts.

Is there any reason the cortexa8 tune file should not be using "hf" by default?

Yes, it's incompatible with anything out there. The only real world app that slightly benefits from it is povray, no demonstrable gains for everything else. This also breaks the 3d drivers.

All in all this is something a DISTRO should opt-in to, not opt-out of.

#2 lore raw
Quoted 8 lines · Koen Kooi

Op 18 aug. 2011, om 08:16 heeft Darren Hart het volgende geschreven:

Quoted 2 lines

From what I could gather, it makes sense to address using mfloat-abi=hard for the beagleboard in the cortexa8 tune file.

It doesn't, actually. Sadly the internet is now full with posts from misinformed meego and debian people about this issue, so I see why someone might think hfp cures cancer and creates world peace.

Quoted 8 lines
Quoted 4 lines

Before I submit this as a pull
request, I'd appreciate a sanity check from the Beagleboard experts.

Is there any reason the cortexa8 tune file should not be using "hf" by default?

Yes, it's incompatible with anything out there. The only real world app that slightly benefits from it is povray, no demonstrable gains for everything else. This also breaks the 3d drivers.

All in all this is something a DISTRO should opt-in to, not opt-out of.

Since I was in the Cc, +1.

#3 lore raw
In reply to Darren Hart
Quoted 8 lines · Darren Hart

From what I could gather, it makes sense to address using mfloat-abi=hard for the beagleboard in the cortexa8 tune file. Before I submit this as a pull request, I'd appreciate a sanity check from the Beagleboard experts.

[...]

mfloat-abi is currently set to soft for beagleboard (cortexa8) and needs to be set to hard to take advantage of the floating point hardware.

Have you benchmarked this change? It isn't really true to say that hf needs to be set to "take advantage" of the FP hardware; you will still get most of the benefit of the VFP without it. I would be surprised if this made much of a difference on any real-world workload.

Changing -mfloat-abi is (obviously) an ABI change and is definitely not the sort of thing to do capriciously. If you apply the patch in its current form then it will make cortexa8 binaries incompatible with everything else by default, which is probably not going to be a good thing. I think this ought to be a DISTRO choice not a machine one.

p.

#4 lore raw
In reply to Darren Hart
Quoted 54 lines · Darren Hart

From what I could gather, it makes sense to address using mfloat-abi=hard
for the beagleboard in the cortexa8 tune file. Before I submit this as a pull request, I'd appreciate a sanity check from the Beagleboard experts.

Is there any reason the cortexa8 tune file should not be using "hf" by default?

Thanks,

Darren

--------
Fixes [YOCTO #1203]

mfloat-abi is currently set to soft for beagleboard (cortexa8) and needs to be set to hard to take advantage of the floating point hardware.

Append "hf" to each of the cortexa8 TUNE_FEATURES and PACKAGE_EXTRA_ARCHS variables. This enables "callconvention-hard" from the included arch-armv7a.inc.

Add a missing closing quote to the VFP AVAILTUNES append operation.

CC Jason Kridner<[email protected]>
CC Koen Kooi<[email protected]>
---
  meta/conf/machine/include/arm/arch-armv7a.inc |    2 +-
  meta/conf/machine/include/tune-cortexa8.inc   |   10 +++++-----
  2 files changed, 6 insertions(+), 6 deletions(-)
meta/conf/machine/include/arm/arch-armv7a.inc +1 -1
index 704f86b..d508352 100644
@@ -20,7 +20,7 @@ PACKAGE_EXTRA_ARCHS_tune-armv7at = "${PACKAGE_EXTRA_ARCHS_tune-armv7t} armv7a ar
  PACKAGE_EXTRA_ARCHS_tune-armv7at-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at} armv7a-vfp-neon armv7at2-vfp-neon"
 
  # VFP Tunes
-AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon
+AVAILTUNES += "armv7hf armv7thf armv7hf-neon armv7thf-neon"
  TUNE_FEATURES_tune-armv7ahf ?= "${TUNE_FEATURES_tune-armv7a} callconvention-hard"
  TUNE_FEATURES_tune-armv7athf ?= "${TUNE_FEATURES_tune-armv7at} callconvention-hard"
  TUNE_FEATURES_tune-armv7ahf-neon ?= "${TUNE_FEATURES_tune-armv7a-neon} callconvention-hard"
meta/conf/machine/include/tune-cortexa8.inc +1 -2
index 02b560c..e7483b9 100644
@@ -6,11 +6,11 @@ TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
 
  AVAILTUNES += "cortexa8 cortexa8t"
-TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7a} cortexa8"
-TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7at} cortexa8"
+TUNE_FEATURES_tune-cortexa8 = "${TUNE_FEATURES_tune-armv7ahf} cortexa8"

meta/conf/machine/include/tune-cortexa8.inc TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations" · line 16

Quoted 10 lines
meta/conf/machine/include/tune-cortexa8.inc +4 -3
+TUNE_FEATURES_tune-cortexa8t = "${TUNE_FEATURES_tune-armv7athf} cortexa8"
  TUNE_FEATURES_tune-cortexa8-neon = "${TUNE_FEATURES_tune-cortexa8} neon"
 
-PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
-PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7at}"
-PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8 = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8t = "${PACKAGE_EXTRA_ARCHS_tune-armv7athf}"
+PACKAGE_EXTRA_ARCHS_tune-cortexa8-neon = "${PACKAGE_EXTRA_ARCHS_tune-armv7ahf-neon}"
 

It it could be made possible then you could work towards making hardfp to be a multilib option along with softfp remaining the default. So people can use certain applications with hardfp which will really benefit from hardfp. General applications may not benefit so much from hardfp ABI