[4/9] arch/arm: do not allow soft-float for armv8a

Message ID bd6e8e2eaf13ecc5e45e360875cfff3494b86a8c.1504444617.git.yann.morin.1998@free.fr
State New
Headers show
Series
  • [1/9] arch/arm: re-order cores choice
Related show

Commit Message

Yann E. MORIN Sept. 3, 2017, 1:17 p.m.
armv8a has made VFPv4 and NEON mandatory, so there is no point in
allowing software floating point, even in 32-bit mode.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/Config.in.arm | 1 +
 1 file changed, 1 insertion(+)

Comments

Yann E. MORIN Sept. 4, 2017, 5:21 p.m. | #1
Thomas, All,

On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly:
> armv8a has made VFPv4 and NEON mandatory, so there is no point in
> allowing software floating point, even in 32-bit mode.

In fact, even though I'm pretty sure that OK in 64-bit, we might still
have a reason to do soft-float in 32-bit mode, if only for legacy
binary-only applications that were built as soft-float way back in the
(not so) good old days...

In which case, we should instead depend on !BR2_ARCH_IS_64.

Thoughts?

Regards,
Yann E. MORIN.

> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
>  arch/Config.in.arm | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index d110d52e2d..0ae6a16a0a 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -374,6 +374,7 @@ choice
>  config BR2_ARM_SOFT_FLOAT
>  	bool "Soft float"
>  	depends on BR2_ARM_EABI
> +	depends on !BR2_ARM_CPU_ARMV8A
>  	select BR2_SOFT_FLOAT
>  	help
>  	  This option allows to use software emulated floating
> -- 
> 2.11.0
>
Thomas Petazzoni Nov. 24, 2017, 10:08 p.m. | #2
Hello,

On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly:
> > armv8a has made VFPv4 and NEON mandatory, so there is no point in
> > allowing software floating point, even in 32-bit mode.  
> 
> In fact, even though I'm pretty sure that OK in 64-bit, we might still
> have a reason to do soft-float in 32-bit mode, if only for legacy
> binary-only applications that were built as soft-float way back in the
> (not so) good old days...
> 
> In which case, we should instead depend on !BR2_ARCH_IS_64.
> 
> Thoughts?

I'm hesitating on this one. I believe the use-case you mention makes
sense, however I believe that it can still be supported with your
proposed patch.

Indeed, even if you want to run a binary-only soft-float application,
it doesn't prevent the rest of your system from using VFP, as long as
you use EABI (and not EABIhf).

The whole reason why EABI passes floating-point arguments into integer
registers is precisely to allow compatibility between soft-float code
and hard-float code. Thanks to that, a soft-float function can call a
hard-float function, and vice-versa.

Therefore, even if you have a binary-only soft-float application, there
is really no reason to build the entire system soft-float.

So, I think your original patch is OK as-is. However, I still see one
inconsistent thing: if we disallow soft-float because ARMv8-A mandates
VFPv4, why would we allow soft-float for ARMv7-A cores that have a
VFP ? To be consistent, we should also disallow soft-float.

Another way to think about this is: is it possible to build an AArch64
soft-float system? do we want to allow the user to select what is
*possible* or what makes sense?

Best regards,

Thomas
Arnout Vandecappelle Nov. 25, 2017, 5:10 p.m. | #3
On 24-11-17 23:08, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote:
>> Thomas, All,
>>
>> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly:
>>> armv8a has made VFPv4 and NEON mandatory, so there is no point in
>>> allowing software floating point, even in 32-bit mode.  
>>
>> In fact, even though I'm pretty sure that OK in 64-bit, we might still
>> have a reason to do soft-float in 32-bit mode, if only for legacy
>> binary-only applications that were built as soft-float way back in the
>> (not so) good old days...
>>
>> In which case, we should instead depend on !BR2_ARCH_IS_64.
>>
>> Thoughts?
> 
> I'm hesitating on this one. I believe the use-case you mention makes
> sense, however I believe that it can still be supported with your
> proposed patch.
> 
> Indeed, even if you want to run a binary-only soft-float application,
> it doesn't prevent the rest of your system from using VFP, as long as
> you use EABI (and not EABIhf).
> 
> The whole reason why EABI passes floating-point arguments into integer
> registers is precisely to allow compatibility between soft-float code
> and hard-float code. Thanks to that, a soft-float function can call a
> hard-float function, and vice-versa.
> 
> Therefore, even if you have a binary-only soft-float application, there
> is really no reason to build the entire system soft-float.
> 
> So, I think your original patch is OK as-is. However, I still see one
> inconsistent thing: if we disallow soft-float because ARMv8-A mandates
> VFPv4, why would we allow soft-float for ARMv7-A cores that have a
> VFP ? To be consistent, we should also disallow soft-float.
> 
> Another way to think about this is: is it possible to build an AArch64
> soft-float system? do we want to allow the user to select what is
> *possible* or what makes sense?

 gcc aarch64 doesn't have a float-abi option, so no it's not possible to build
with soft-float. So the depends on BR2_ARM_EABI is certainly needed.

 That said, I don't think it makes a lot of sense to add extra 'depends on'
lines just to avoid that the user would select an option that probably doesn't
make sense. We already make sure that the default is appropriate. Let's not make
our life more difficult.

 So I'd say: reject this patch.

 Regards,
 Arnout
Yann E. MORIN Nov. 26, 2017, 11:12 a.m. | #4
Arnout, All,

On 2017-11-25 18:10 +0100, Arnout Vandecappelle spake thusly:
> On 24-11-17 23:08, Thomas Petazzoni wrote:
> > Hello,
> > 
> > On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote:
> >> Thomas, All,
> >>
> >> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly:
> >>> armv8a has made VFPv4 and NEON mandatory, so there is no point in
> >>> allowing software floating point, even in 32-bit mode.  
> >>
> >> In fact, even though I'm pretty sure that OK in 64-bit, we might still
> >> have a reason to do soft-float in 32-bit mode, if only for legacy
> >> binary-only applications that were built as soft-float way back in the
> >> (not so) good old days...
> >>
> >> In which case, we should instead depend on !BR2_ARCH_IS_64.
> >>
> >> Thoughts?
> > 
> > I'm hesitating on this one. I believe the use-case you mention makes
> > sense, however I believe that it can still be supported with your
> > proposed patch.
> > 
> > Indeed, even if you want to run a binary-only soft-float application,
> > it doesn't prevent the rest of your system from using VFP, as long as
> > you use EABI (and not EABIhf).
> > 
> > The whole reason why EABI passes floating-point arguments into integer
> > registers is precisely to allow compatibility between soft-float code
> > and hard-float code. Thanks to that, a soft-float function can call a
> > hard-float function, and vice-versa.
> > 
> > Therefore, even if you have a binary-only soft-float application, there
> > is really no reason to build the entire system soft-float.
> > 
> > So, I think your original patch is OK as-is. However, I still see one
> > inconsistent thing: if we disallow soft-float because ARMv8-A mandates
> > VFPv4, why would we allow soft-float for ARMv7-A cores that have a
> > VFP ? To be consistent, we should also disallow soft-float.
> > 
> > Another way to think about this is: is it possible to build an AArch64
> > soft-float system? do we want to allow the user to select what is
> > *possible* or what makes sense?
> 
>  gcc aarch64

It's not about aarch64, it's about aarch32, i.e. an armv8a core running
in 32-bit mode.

> doesn't have a float-abi option, so no it's not possible to build
> with soft-float. So the depends on BR2_ARM_EABI is certainly needed.
> 
>  That said, I don't think it makes a lot of sense to add extra 'depends on'
> lines just to avoid that the user would select an option that probably doesn't
> make sense. We already make sure that the default is appropriate. Let's not make
> our life more difficult.

It's not about making *our* lives more dificult or easier. It's about
making the user's lives easier.

If there is a prompt that offers an option, but that has no impact on
the resulting output, then that prompt should not exist. Otherwise, it
is very confusing.

Regards,
Yann E. MORIN.

>  So I'd say: reject this patch.
> 
>  Regards,
>  Arnout
> 
> 
> -- 
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
Yann E. MORIN Nov. 26, 2017, 11:18 a.m. | #5
Arnout, Thomas, All,

On 2017-11-26 12:12 +0100, Yann E. MORIN spake thusly:
> On 2017-11-25 18:10 +0100, Arnout Vandecappelle spake thusly:
> > On 24-11-17 23:08, Thomas Petazzoni wrote:
> > > On Mon, 4 Sep 2017 19:21:37 +0200, Yann E. MORIN wrote:
> > >> Thomas, All,
> > >>
> > >> On 2017-09-03 15:17 +0200, Yann E. MORIN spake thusly:
> > >>> armv8a has made VFPv4 and NEON mandatory, so there is no point in
> > >>> allowing software floating point, even in 32-bit mode.  
> > >>
> > >> In fact, even though I'm pretty sure that OK in 64-bit, we might still
> > >> have a reason to do soft-float in 32-bit mode, if only for legacy
> > >> binary-only applications that were built as soft-float way back in the
> > >> (not so) good old days...
> > >>
> > >> In which case, we should instead depend on !BR2_ARCH_IS_64.
> > >>
> > >> Thoughts?
> > > 
> > > I'm hesitating on this one. I believe the use-case you mention makes
> > > sense, however I believe that it can still be supported with your
> > > proposed patch.
> > > 
> > > Indeed, even if you want to run a binary-only soft-float application,
> > > it doesn't prevent the rest of your system from using VFP, as long as
> > > you use EABI (and not EABIhf).
> > > 
> > > The whole reason why EABI passes floating-point arguments into integer
> > > registers is precisely to allow compatibility between soft-float code
> > > and hard-float code. Thanks to that, a soft-float function can call a
> > > hard-float function, and vice-versa.
> > > 
> > > Therefore, even if you have a binary-only soft-float application, there
> > > is really no reason to build the entire system soft-float.
> > > 
> > > So, I think your original patch is OK as-is. However, I still see one
> > > inconsistent thing: if we disallow soft-float because ARMv8-A mandates
> > > VFPv4, why would we allow soft-float for ARMv7-A cores that have a
> > > VFP ? To be consistent, we should also disallow soft-float.
> > > 
> > > Another way to think about this is: is it possible to build an AArch64
> > > soft-float system? do we want to allow the user to select what is
> > > *possible* or what makes sense?
> > 
> >  gcc aarch64
> 
> It's not about aarch64, it's about aarch32, i.e. an armv8a core running
> in 32-bit mode.
> 
> > doesn't have a float-abi option, so no it's not possible to build
> > with soft-float. So the depends on BR2_ARM_EABI is certainly needed.
> > 
> >  That said, I don't think it makes a lot of sense to add extra 'depends on'
> > lines just to avoid that the user would select an option that probably doesn't
> > make sense. We already make sure that the default is appropriate. Let's not make
> > our life more difficult.
> 
> It's not about making *our* lives more dificult or easier. It's about
> making the user's lives easier.
> 
> If there is a prompt that offers an option, but that has no impact on
> the resulting output, then that prompt should not exist. Otherwise, it
> is very confusing.

Damned, I hadn't finished my mail...

> >  So I'd say: reject this patch.

But seeing the argument from Thomas, yes it does not make sense to hide
soft-float anyway.

Regards,
Yann E. MORIN.

Patch

diff --git a/arch/Config.in.arm b/arch/Config.in.arm
index d110d52e2d..0ae6a16a0a 100644
--- a/arch/Config.in.arm
+++ b/arch/Config.in.arm
@@ -374,6 +374,7 @@  choice
 config BR2_ARM_SOFT_FLOAT
 	bool "Soft float"
 	depends on BR2_ARM_EABI
+	depends on !BR2_ARM_CPU_ARMV8A
 	select BR2_SOFT_FLOAT
 	help
 	  This option allows to use software emulated floating