[PATCH][RFC] cortexa8: use hard floating point

[PATCH][RFC] cortexa8: use hard floating point

[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.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Koen Kooi <koen@dominion.thruhere.net>
---
 meta/conf/machine/include/arm/arch-armv7a.inc |    2 +-
 meta/conf/machine/include/tune-cortexa8.inc   |   10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
index 704f86b..d508352 100644
--- a/meta/conf/machine/include/arm/arch-armv7a.inc
+++ b/meta/conf/machine/include/arm/arch-armv7a.inc
@@ -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"
diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
index 02b560c..e7483b9 100644
--- a/meta/conf/machine/include/tune-cortexa8.inc
+++ b/meta/conf/machine/include/tune-cortexa8.inc
@@ -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}"
 
-- 
1.7.1
-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [PATCH][RFC] cortexa8: use hard floating point

[Koen Kooi]

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

> 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.

> 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.

Re: [PATCH][RFC] cortexa8: use hard floating point

[Phil Blundell]

On Wed, 2011-08-17 at 23:16 -0700, Darren Hart wrote:
> 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.

Re: [PATCH][RFC] cortexa8: use hard floating point

[Jason Kridner]

On Aug 18, 2011, at 3:11 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:

> 
> Op 18 aug. 2011, om 08:16 heeft Darren Hart het volgende geschreven:
> 
>> 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.
> 
>> 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.

Re: [PATCH][RFC] cortexa8: use hard floating point

[Khem Raj]

On 8/17/2011 11:16 PM, Darren Hart wrote:
>  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.
>
> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
> CC: Jason Kridner<jkridner@beagleboard.org>
> CC: Koen Kooi<koen@dominion.thruhere.net>
> ---
>   meta/conf/machine/include/arm/arch-armv7a.inc |    2 +-
>   meta/conf/machine/include/tune-cortexa8.inc   |   10 +++++-----
>   2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/arch-armv7a.inc b/meta/conf/machine/include/arm/arch-armv7a.inc
> index 704f86b..d508352 100644
> --- a/meta/conf/machine/include/arm/arch-armv7a.inc
> +++ b/meta/conf/machine/include/arm/arch-armv7a.inc
> @@ -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"
> diff --git a/meta/conf/machine/include/tune-cortexa8.inc b/meta/conf/machine/include/tune-cortexa8.inc
> index 02b560c..e7483b9 100644
> --- a/meta/conf/machine/include/tune-cortexa8.inc
> +++ b/meta/conf/machine/include/tune-cortexa8.inc
> @@ -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}"
>

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