public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@rivosinc.com>
To: libc-alpha@sourceware.org
Cc: Kito Cheng <kito.cheng@sifive.com>,
	Palmer Dabbelt <palmer@rivosinc.com>,
	lco=20Dijkstra=C2=A0?= <Wilco.Dijkstra@arm.com>
Subject: [COMMITTED 2/2] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1
Date: Fri, 28 Apr 2023 07:04:27 -0700	[thread overview]
Message-ID: <20230428140427.13133-2-palmer@rivosinc.com> (raw)
In-Reply-To: <20230428140427.13133-1-palmer@rivosinc.com>

From: Kito Cheng <kito.cheng@sifive.com>

__GLIBC_FLT_EVAL_METHOD will effect the definition of float_t and
double_t, currently we'll set __GLIBC_FLT_EVAL_METHOD to 2 when
__FLT_EVAL_METHOD__ is -1, that means we'll define float_t and double_t
to long double.

However some target isn't natively (HW) support long double like AArch64 and
RISC-V, they defined long double as 128-bits IEEE 754 floating point type.

That means setting __GLIBC_FLT_EVAL_METHOD to 2 will cause very inefficient
code gen for those target who didn't provide native support for long
double, and that's violate the spirit float_t and double_t - most efficient
types at least as wide as float and double.

So this patch propose to remap __GLIBC_FLT_EVAL_METHOD to 0 rather than
2 when __FLT_EVAL_METHOD__ is -1, which means we'll use float/double
rather than long double for float_t and double_t.

Note: __FLT_EVAL_METHOD__ == -1 means the precision is indeterminable,
      which means compiler might using indeterminable precision during
      optimization/code gen, clang will set this value to -1 when fast
      math is enabled.

Note: Default definition float_t and double_t in current glibc:
      |  __GLIBC_FLT_EVAL_METHOD | float_t     | double_t
      |               0 or 16    | float       | double
      |               1          | double      | doulbe
      |               2          | long double | long double
      More complete list see math/math.h

Note: RISC-V has defined ISA extension to support 128-bits IEEE 754
      floating point operations, but only rare RISC-V core will implement that.

Related link:

[1] LLVM issue (__FLT_EVAL_METHOD__ is set to -1 with Ofast. #60781):
    https://github.com/llvm/llvm-project/issues/60781
[2] Last version of this patch: https://sourceware.org/pipermail/libc-alpha/2023-February/145622.html

Acked-by: Palmer Dabbelt <palmer@rivosinc.com> # RISC-V
Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>
Link: https://inbox.sourceware.org/libc-alpha/20230314151948.12892-1-kito.cheng@sifive.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
---
 bits/flt-eval-method.h | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/bits/flt-eval-method.h b/bits/flt-eval-method.h
index 75f57b9a0e..f9262d7d0b 100644
--- a/bits/flt-eval-method.h
+++ b/bits/flt-eval-method.h
@@ -26,14 +26,12 @@
    -1.  */
 
 /* In the default version of this header, follow __FLT_EVAL_METHOD__.
-   -1 is mapped to 2 (considering evaluation as long double to be a
-   conservatively safe assumption), and if __FLT_EVAL_METHOD__ is not
-   defined then assume there is no excess precision and use the value
-   0.  */
+   If __FLT_EVAL_METHOD__ is not defined or set to -1, assume there is no
+   excess precision and use the value 0 (this is correct for most targets). */
 
 #ifdef __FLT_EVAL_METHOD__
 # if __FLT_EVAL_METHOD__ == -1
-#  define __GLIBC_FLT_EVAL_METHOD	2
+#  define __GLIBC_FLT_EVAL_METHOD	0
 # else
 #  define __GLIBC_FLT_EVAL_METHOD	__FLT_EVAL_METHOD__
 # endif
-- 
2.40.0


  reply	other threads:[~2023-04-28 14:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28 14:04 [COMMITTED 1/2] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC Palmer Dabbelt
2023-04-28 14:04 ` Palmer Dabbelt [this message]
2023-04-28 17:45 ` Joseph Myers
2023-04-28 17:50   ` Palmer Dabbelt
     [not found] ` <d8613f93-ecef-fa32-3fc1-7cc9c4ff189e@linux.vnet.ibm.com>
2023-05-03 14:46   ` Fwd: " Manjul Mohan

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=20230428140427.13133-2-palmer@rivosinc.com \
    --to=palmer@rivosinc.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=kito.cheng@sifive.com \
    --cc=libc-alpha@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).