Reset HWCAP2_AFP bits in FPCR for default fenv.

Reset HWCAP2_AFP bits in FPCR for default fenv.

[Tejas Belagod]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Hi,

The AFP feature (Alternate floating-point behavior) was added in Armv8.7-A and
introduced new FPCR bits.

Currently, HWCAP2_AFP bits (bit 0, 1, 2) in FPCR are preserved when fenv is
set to default environment.  This is a deviation from standard behavior.
Clear these bits when setting the fenv to default.

There is no libc API to modify the new FPCR bits.  Restoring those bits matters
if the user changed them directly.

OK for master?

Thanks,
Tejas.

[-- Attachment #2: afp.txt --]
[-- Type: text/plain, Size: 530 bytes --]

diff --git a/sysdeps/aarch64/fpu/fpu_control.h b/sysdeps/aarch64/fpu/fpu_control.h
index 764ed5cdbb6a90a4d6ac9af1f8874fd71c379e62..429f4910e7a165a7ba8170b173c4fbb3960afa3f 100644
--- a/sysdeps/aarch64/fpu/fpu_control.h
+++ b/sysdeps/aarch64/fpu/fpu_control.h
@@ -46,7 +46,7 @@
    contents. These two masks indicate which bits in each of FPCR and
    FPSR should not be changed.  */
 
-#define _FPU_RESERVED		0xfe0fe0ff
+#define _FPU_RESERVED		0xfe0fe0f8
 #define _FPU_FPSR_RESERVED	0x0fffffe0
 
 #define _FPU_DEFAULT		0x00000000

Re: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Florian Weimer]

* Tejas Belagod via Libc-alpha:

> The AFP feature (Alternate floating-point behavior) was added in
> Armv8.7-A and introduced new FPCR bits.
>
> Currently, HWCAP2_AFP bits (bit 0, 1, 2) in FPCR are preserved when
> fenv is set to default environment.  This is a deviation from standard
> behavior.  Clear these bits when setting the fenv to default.
>
> There is no libc API to modify the new FPCR bits.  Restoring those
> bits matters if the user changed them directly.
>
> OK for master?

What do you propose as commit message?

I think we have that definition of _FPU_RESERVED because the we cannot
know the semantics of those bits (obviosuly), and changing them
underneath the user's code could be wrong.

What do these bits do, actually?  If this adds additional FPU state, how
does it interact with compiler behavior and optimizations?  Can it even
be safely changed after process startup?

Thanks,
Florian

Re: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Szabolcs Nagy]

The 06/29/2022 11:54, Florian Weimer wrote:
> * Tejas Belagod via Libc-alpha:
> 
> > The AFP feature (Alternate floating-point behavior) was added in
> > Armv8.7-A and introduced new FPCR bits.
> >
> > Currently, HWCAP2_AFP bits (bit 0, 1, 2) in FPCR are preserved when
> > fenv is set to default environment.  This is a deviation from standard
> > behavior.  Clear these bits when setting the fenv to default.
> >
> > There is no libc API to modify the new FPCR bits.  Restoring those
> > bits matters if the user changed them directly.
> >
> > OK for master?
> 
> What do you propose as commit message?
> 
> I think we have that definition of _FPU_RESERVED because the we cannot
> know the semantics of those bits (obviosuly), and changing them
> underneath the user's code could be wrong.
> 
> What do these bits do, actually?  If this adds additional FPU state, how
> does it interact with compiler behavior and optimizations?  Can it even
> be safely changed after process startup?

i think you will have to check the details in the arm arm
https://developer.arm.com/documentation/ddi0487/latest

in short, the new bits

FPCR.NEP: changes output of scalar fp instructions in top vector lanes.
FPCR.AH: changes flush to zero exception, underflow and nan propagation.
FPCR.FIZ: subnormal inputs are flushed to zero (instead of outputs).

(note that the alternate fp behaviour is carefully designed so
it's easy to emulate fp instructions of other architectures, i.e.
the bits are likely not used to change math library behaviour but
to execute a foreign binary on aarch64.)

technically these should be 0 in c code (then save/restore is noop).
it seems the existing reserved bits are not consistent:

- DN is reserved (when set, default nan is returned instead of
  propagating nan payload)

- FZ is not reserved (subnormal flush to zero)

These are non-conforming settings so fenv apis could ignore both
or save/restore both.

i don't have a strong opinion, but i thought it made sense to
restore all these special bits with fesetenv(FE_DFL_ENV).
(e.g. in an async signal handler one could do

  fegetenv(&e);
  fesetenv(FE_DFL_ENV);
  // fp operations
  fesetenv(&e);

to get sane fenv. this is ub in iso c, but not unreasonable.)

Re: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Joseph Myers]

On Wed, 29 Jun 2022, Szabolcs Nagy via Libc-alpha wrote:

> i don't have a strong opinion, but i thought it made sense to
> restore all these special bits with fesetenv(FE_DFL_ENV).

Yes, I think FE_DFL_ENV (and FE_DFL_MODE) should cover all such 
architecture-specific control settings, even when we also don't support 
the use of most floating-point APIs with non-default values of those 
settings.

-- 
Joseph S. Myers
joseph@codesourcery.com

RE: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Tejas Belagod]

> -----Original Message-----
> From: Joseph Myers <joseph@codesourcery.com>
> Sent: Wednesday, June 29, 2022 10:24 PM
> To: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
> Cc: Florian Weimer <fweimer@redhat.com>; Tejas Belagod
> <Tejas.Belagod@arm.com>; Tejas Belagod via Libc-alpha <libc-
> alpha@sourceware.org>
> Subject: Re: Reset HWCAP2_AFP bits in FPCR for default fenv.
> 
> On Wed, 29 Jun 2022, Szabolcs Nagy via Libc-alpha wrote:
> 
> > i don't have a strong opinion, but i thought it made sense to restore
> > all these special bits with fesetenv(FE_DFL_ENV).
> 
> Yes, I think FE_DFL_ENV (and FE_DFL_MODE) should cover all such
> architecture-specific control settings, even when we also don't support the
> use of most floating-point APIs with non-default values of those settings.
> 

Thanks all for your comments. 

Florian, given the explanations from Szabolcs and Joseph, do you have any objections to this change?

Thanks,
Tejas.

> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Florian Weimer]

* Tejas Belagod:

>> -----Original Message-----
>> From: Joseph Myers <joseph@codesourcery.com>
>> Sent: Wednesday, June 29, 2022 10:24 PM
>> To: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
>> Cc: Florian Weimer <fweimer@redhat.com>; Tejas Belagod
>> <Tejas.Belagod@arm.com>; Tejas Belagod via Libc-alpha <libc-
>> alpha@sourceware.org>
>> Subject: Re: Reset HWCAP2_AFP bits in FPCR for default fenv.
>> 
>> On Wed, 29 Jun 2022, Szabolcs Nagy via Libc-alpha wrote:
>> 
>> > i don't have a strong opinion, but i thought it made sense to restore
>> > all these special bits with fesetenv(FE_DFL_ENV).
>> 
>> Yes, I think FE_DFL_ENV (and FE_DFL_MODE) should cover all such
>> architecture-specific control settings, even when we also don't support the
>> use of most floating-point APIs with non-default values of those settings.
>> 
>
> Thanks all for your comments. 
>
> Florian, given the explanations from Szabolcs and Joseph, do you have
> any objections to this change?

No objection to the change itself, but you didn't post the proposed
commit message.  Please mention “aarch64” in the subject.

Thanks,
Florian

RE: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Tejas Belagod]

Thanks. 

Sorry, I intended the original mail body without the 'OK for master?' as the commit message. I shall re-post the patch with the correct formatting.

Thanks,
Tejas.

> -----Original Message-----
> From: Florian Weimer <fweimer@redhat.com>
> Sent: Thursday, June 30, 2022 4:13 PM
> To: Tejas Belagod <Tejas.Belagod@arm.com>
> Cc: Joseph Myers <joseph@codesourcery.com>; Szabolcs Nagy
> <Szabolcs.Nagy@arm.com>; Tejas Belagod via Libc-alpha <libc-
> alpha@sourceware.org>
> Subject: Re: Reset HWCAP2_AFP bits in FPCR for default fenv.
> 
> * Tejas Belagod:
> 
> >> -----Original Message-----
> >> From: Joseph Myers <joseph@codesourcery.com>
> >> Sent: Wednesday, June 29, 2022 10:24 PM
> >> To: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
> >> Cc: Florian Weimer <fweimer@redhat.com>; Tejas Belagod
> >> <Tejas.Belagod@arm.com>; Tejas Belagod via Libc-alpha <libc-
> >> alpha@sourceware.org>
> >> Subject: Re: Reset HWCAP2_AFP bits in FPCR for default fenv.
> >>
> >> On Wed, 29 Jun 2022, Szabolcs Nagy via Libc-alpha wrote:
> >>
> >> > i don't have a strong opinion, but i thought it made sense to
> >> > restore all these special bits with fesetenv(FE_DFL_ENV).
> >>
> >> Yes, I think FE_DFL_ENV (and FE_DFL_MODE) should cover all such
> >> architecture-specific control settings, even when we also don't
> >> support the use of most floating-point APIs with non-default values of
> those settings.
> >>
> >
> > Thanks all for your comments.
> >
> > Florian, given the explanations from Szabolcs and Joseph, do you have
> > any objections to this change?
> 
> No objection to the change itself, but you didn't post the proposed commit
> message.  Please mention “aarch64” in the subject.
> 
> Thanks,
> Florian

Re: Reset HWCAP2_AFP bits in FPCR for default fenv.

[Szabolcs Nagy]

The 07/01/2022 07:40, Tejas Belagod wrote:
> I've attached the new patch with all the comments addressed. I hope I've done the right thing with the mail reply format and the patch attachment.

the attachment is binary so patchwork didnt pick it up
and it makes it difficult to reply inline.

it also uses different email address than you post from.

can you try to use git send-email?
(and make it a PATCH v2)

Reset HWCAP2_AFP bits in FPCR for default fenv.

[Tejas Belagod]

[-- Attachment #1: Type: text/plain, Size: 2499 bytes --]



> -----Original Message-----
> From: Libc-alpha <libc-alpha-
> bounces+belagod=gcc.gnu.org@sourceware.org> On Behalf Of Tejas
> Belagod via Libc-alpha
> Sent: Thursday, June 30, 2022 4:26 PM
> To: Florian Weimer <fweimer@redhat.com>
> Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>; Tejas Belagod via Libc-alpha
> <libc-alpha@sourceware.org>; Joseph Myers <joseph@codesourcery.com>
> Subject: RE: Reset HWCAP2_AFP bits in FPCR for default fenv.
> 
> Thanks.
> 
> Sorry, I intended the original mail body without the 'OK for master?' as the
> commit message. I shall re-post the patch with the correct formatting.
> 

I've attached the new patch with all the comments addressed. I hope I've done the right thing with the mail reply format and the patch attachment.

Thanks,
Tejas.

> Thanks,
> Tejas.
> 
> > -----Original Message-----
> > From: Florian Weimer <fweimer@redhat.com>
> > Sent: Thursday, June 30, 2022 4:13 PM
> > To: Tejas Belagod <Tejas.Belagod@arm.com>
> > Cc: Joseph Myers <joseph@codesourcery.com>; Szabolcs Nagy
> > <Szabolcs.Nagy@arm.com>; Tejas Belagod via Libc-alpha <libc-
> > alpha@sourceware.org>
> > Subject: Re: Reset HWCAP2_AFP bits in FPCR for default fenv.
> >
> > * Tejas Belagod:
> >
> > >> -----Original Message-----
> > >> From: Joseph Myers <joseph@codesourcery.com>
> > >> Sent: Wednesday, June 29, 2022 10:24 PM
> > >> To: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
> > >> Cc: Florian Weimer <fweimer@redhat.com>; Tejas Belagod
> > >> <Tejas.Belagod@arm.com>; Tejas Belagod via Libc-alpha <libc-
> > >> alpha@sourceware.org>
> > >> Subject: Re: Reset HWCAP2_AFP bits in FPCR for default fenv.
> > >>
> > >> On Wed, 29 Jun 2022, Szabolcs Nagy via Libc-alpha wrote:
> > >>
> > >> > i don't have a strong opinion, but i thought it made sense to
> > >> > restore all these special bits with fesetenv(FE_DFL_ENV).
> > >>
> > >> Yes, I think FE_DFL_ENV (and FE_DFL_MODE) should cover all such
> > >> architecture-specific control settings, even when we also don't
> > >> support the use of most floating-point APIs with non-default values
> > >> of
> > those settings.
> > >>
> > >
> > > Thanks all for your comments.
> > >
> > > Florian, given the explanations from Szabolcs and Joseph, do you
> > > have any objections to this change?
> >
> > No objection to the change itself, but you didn't post the proposed
> > commit message.  Please mention “aarch64” in the subject.
> >
> > Thanks,
> > Florian


[-- Attachment #2: 0001-AArch64-Reset-HWCAP2_AFP-bits-in-FPCR-for-default-fe.patch --]
[-- Type: application/octet-stream, Size: 1219 bytes --]

From eb7a8507324bbf10ac902e73645d1c5e200eee95 Mon Sep 17 00:00:00 2001
From: Tejas Belagod <tbelagod@arm.com>
Date: Mon, 27 Jun 2022 07:41:37 +0100
Subject: [PATCH] AArch64: Reset HWCAP2_AFP bits in FPCR for default fenv

The AFP feature (Alternate floating-point behavior) was added in armv8.7 and
introduced new FPCR bits.

Currently, HWCAP2_AFP bits (bit 0, 1, 2) in FPCR are preserved when fenv is
set to default environment.  This is a deviation from standard behaviour.
Clear these bits when setting the fenv to default.

There is no libc API to modify the new FPCR bits.  Restoring those bits matters
if the user changed them directly.
---
 sysdeps/aarch64/fpu/fpu_control.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sysdeps/aarch64/fpu/fpu_control.h b/sysdeps/aarch64/fpu/fpu_control.h
index 764ed5cdbb..429f4910e7 100644
--- a/sysdeps/aarch64/fpu/fpu_control.h
+++ b/sysdeps/aarch64/fpu/fpu_control.h
@@ -46,7 +46,7 @@
    contents. These two masks indicate which bits in each of FPCR and
    FPSR should not be changed.  */
 
-#define _FPU_RESERVED		0xfe0fe0ff
+#define _FPU_RESERVED		0xfe0fe0f8
 #define _FPU_FPSR_RESERVED	0x0fffffe0
 
 #define _FPU_DEFAULT		0x00000000
-- 
2.17.1