public inbox for glibc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Vineet Gupta <vgupta@sourceware.org>
To: glibc-cvs@sourceware.org
Subject: [glibc] ARC: fp: (micro)optimize FPU_STATUS read by eliding FWE bit clearing
Date: Wed, 21 Jul 2021 20:15:26 +0000 (GMT)	[thread overview]
Message-ID: <20210721201526.6AC183857C71@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=31aefa93f3e9a49b7a493d410acb70108e176d61

commit 31aefa93f3e9a49b7a493d410acb70108e176d61
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Fri Jul 9 14:56:18 2021 -0700

    ARC: fp: (micro)optimize FPU_STATUS read by eliding FWE bit clearing
    
    Any FPU_STATUS write needs setting the FWE bit (31) whcih just provides
    a "control signal" to enable explicit write (vs. the side-effect of FPU
    instructions).  However this bit is RAZ and write-only, thus effectively
    never stored in FPU_STATUS register. Thus when reading the register
    there is no need to clear it. This shaves off a BCLR instruction from
    the fe*exceptino family of functions and while no big deal still makes
    sense to do.
    
    This came up when debugging a race in math/test-fenv-tls [1]
    
    [1]: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/54
    
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

Diff:
---
 sysdeps/arc/fpu_control.h | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/sysdeps/arc/fpu_control.h b/sysdeps/arc/fpu_control.h
index c7d101e783..ae4348321c 100644
--- a/sysdeps/arc/fpu_control.h
+++ b/sysdeps/arc/fpu_control.h
@@ -81,21 +81,20 @@ typedef unsigned int fpu_control_t;
 #  define _FPU_SETCW(cw) __asm__ volatile ("sr %0, [0x300]" : : "r" (cw))
 
 /*  Macros for accessing the hardware status word.
-    FWE bit is special as it controls if actual status bits could be wrritten
-    explicitly (other than FPU instructions). We handle it here to keep the
-    callers agnostic of it:
-      - clear it out when reporting status bits
-      - always set it when changing status bits.  */
+    Writing to FPU_STATUS requires a "control" bit FWE to be able to set the
+    exception flags directly (as opposed to side-effects of FP instructions).
+    That is done in the macro here to keeps callers agnostic of this detail.
+    And given FWE is write-only and RAZ, no need to "clear" it in _FPU_GETS
+    macro.  */
 #  define _FPU_GETS(cw)				\
     __asm__ volatile ("lr   %0, [0x301]	\r\n" 	\
-                      "bclr %0, %0, 31	\r\n" 	\
                       : "=r" (cw))
 
 #  define _FPU_SETS(cw)				\
     do {					\
-      unsigned int __tmp = 0x80000000 | (cw);	\
+      unsigned int __fwe = 0x80000000 | (cw);	\
       __asm__ volatile ("sr  %0, [0x301] \r\n" 	\
-                        : : "r" (__tmp));	\
+                        : : "r" (__fwe));	\
     } while (0)
 
 /* Default control word set at startup.  */


                 reply	other threads:[~2021-07-21 20:15 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210721201526.6AC183857C71@sourceware.org \
    --to=vgupta@sourceware.org \
    --cc=glibc-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).