public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Kito Cheng <kito.cheng@sifive.com>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: libc-alpha@sourceware.org, joseph@codesourcery.com,
	jeffreyalaw@gmail.com,  Darius Rad <darius@bluespec.com>,
	christoph.muellner@vrull.eu,  DJ Delorie <dj@redhat.com>,
	Andrew Waterman <andrew@sifive.com>,
	 Wilco Dijkstra <Wilco.Dijkstra@arm.com>
Subject: Re: [PATCH] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1
Date: Thu, 9 Mar 2023 22:14:55 +0800	[thread overview]
Message-ID: <CALLt3Tj51VjoOC5GzJT0mrRDqsAQmtwXN3qJANoNGEjHq5qEyg@mail.gmail.com> (raw)
In-Reply-To: <mhng-f034feb7-c516-47ac-8c2d-eb652d704a62@palmer-ri-x1c9a>

ping


On Sun, Feb 19, 2023 at 2:29 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> On Thu, 16 Feb 2023 18:26:46 PST (-0800), kito.cheng@sifive.com wrote:
> > ---
> > We were intending to update RISC-V's setting only, but after discussion
> > with Wilco Dijkstra, we decide to change the generic one instead of RISC-V only
> > since it also fix inefficient issue for float_t and double_t.
> > ---
> >
> > __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
> >
> > Ref:
> >
> > [1] Definition of FLT_EVAL_METHOD from C99 spec:
> > C99 Spec draft: (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
> >
> > Except for assignment and cast (which remove all extra range and precision), the values
> > of operations with floating operands and values subject to the usual arithmetic
> > conversions and of floating constants are evaluated to a format whose range and precision
> > may be greater than required by the type. The use of evaluation formats is characterized
> > by the implementation-defined value of FLT_EVAL_METHOD:
> > 19)
> >
> >   -1 indeterminable;
> >   0 evaluate all operations and constants just to the range and precision of the
> >     type;
> >   1 evaluate operations and constants of type float and double to the
> >     range and precision of the double type, evaluate long double
> >     operations and constants to the range and precision of the long double
> >     type;
> >   2 evaluate all operations and constants to the range and precision of the
> >     long double type.
> >
> > All other negative values for FLT_EVAL_METHOD characterize implementation-defined
> > behavior.
> >
> > [2] Definition of float_t and double_t in C99 spec:
> >
> > C99 Spec draft: (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf)
> >
> > 7.12
> >
> > ...
> >
> > The types
> > float_t
> > double_t
> > are floating types at least as wide as float and double, respectively, and such that
> > double_t is at least as wide as float_t. If FLT_EVAL_METHOD equals 0,
> > float_t and double_t are float and double, respectively; if
> > FLT_EVAL_METHOD equals 1, they are both double; if FLT_EVAL_METHOD equals
> > 2, they are both long double; and for other values of FLT_EVAL_METHOD, they are
> > otherwise implementation-defined.199)
> >
> > 199) The types float_t and double_t are intended to be the implementation’s most efficient types at
> > least as wide as float and double, respectively. For FLT_EVAL_METHOD equal 0, 1, or 2, the
> > type float_t is the narrowest type used by the implementation to
> > evaluate floating expressions.
> > ---
> >  bits/flt-eval-method.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/bits/flt-eval-method.h b/bits/flt-eval-method.h
> > index 75f57b9a0e..b6be0a1e43 100644
> > --- a/bits/flt-eval-method.h
> > +++ b/bits/flt-eval-method.h
> > @@ -26,14 +26,14 @@
> >     -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
> > +   -1 is mapped to 0 (considering evaluation as same precision 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.  */
> >
> >  #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
>
> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> # RISC-V
>
> though we should have a global reviewed look at this now that it's
> touching everything.

  reply	other threads:[~2023-03-09 14:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17  2:26 Kito Cheng
2023-02-18 18:29 ` Palmer Dabbelt
2023-03-09 14:14   ` Kito Cheng [this message]
2023-03-09 14:33     ` Xi Ruoyao
2023-03-09 14:59       ` Kito Cheng
2023-03-09 15:18         ` Xi Ruoyao
2023-03-09 16:03           ` Kito Cheng
2023-03-09 16:20           ` Wilco Dijkstra
2023-03-09 19:37     ` Wilco Dijkstra

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=CALLt3Tj51VjoOC5GzJT0mrRDqsAQmtwXN3qJANoNGEjHq5qEyg@mail.gmail.com \
    --to=kito.cheng@sifive.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=andrew@sifive.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=darius@bluespec.com \
    --cc=dj@redhat.com \
    --cc=jeffreyalaw@gmail.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=palmer@rivosinc.com \
    /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).