From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by sourceware.org (Postfix) with ESMTPS id 62BC83858C74 for ; Thu, 9 Mar 2023 15:00:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 62BC83858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lf1-x12c.google.com with SMTP id i9so2652871lfc.6 for ; Thu, 09 Mar 2023 07:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1678374008; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Cx1A78d/jlmLZgEShbt4an2ZRhxVJnGCbBAD0t9J2oY=; b=e3XJRxJLg5LOuyhcIVJ04GDYwG09Na5uszsE24865hLX0Nhq/thdlHjtNl7AkiYRx0 08NxZma9QH2u3hk22DiPrUFF8h1ZGElBQqPQy2jRn6K2bPaNTFO5Zt/Cf9vSDtOjCdva aTKOuEsS/dCWI387rvPOcV19gdhF9PNNdLMKUUtdsgN0yNPBkVjLZJm3S6TwSrPxsOQu nhIyi5zafOdNVEG5ulhXnysnWd9Ix0ZfQfHTC4iVPXvs8w8xpFJJNSM2SXpaNNawcP0c dDr4CBCciJDO82NXMlfJfSH0h3HL7Lc+/y0iy578hh1C/Glx9lVNLzjU1xU0M8cvkaMv MQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678374008; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Cx1A78d/jlmLZgEShbt4an2ZRhxVJnGCbBAD0t9J2oY=; b=JHwLAPefgFkLkjuatwMybX40HGVOnUI+N/gVzru/Kl9xGtRhun5IyDdDfSS8YVtahy NeBxxniZqxzjGyed2xrm46qCAVzfUMsLlTNTXtbTW+DEweRW0zvFfJRnVom59wmpUtK5 WSr66xek0cM+wSzzGmq2UKAUxvjtPHwUNVzA6KyP5719e5C2PltGtxQzHBx/e11zfxof o9dypgn3M/R9nwdGyCwaSXbslWTHOxLhgcv+Vu/Uys5fORdGOrwWF3qw5CxiIKVG8V7t xF+BNMIJMRCSG0HfSBKSjKvcqDg0gMsXzCQ8eFjLbc6wOML8a2yhgqOZTUagiet9KU4b JTMg== X-Gm-Message-State: AO0yUKWtSzcqa1Ipx14SmUJgYXLu5hXz2DWKXzWQBGaWQG1ewIsFU+4v EiwNuJElyxswKic13leuXrML2kF/1MSvibjlcoJWNg== X-Google-Smtp-Source: AK7set/FQyzQ9vim91ifcJ2AnOVzcdKnsB1SMFBFLyqQ3yjVdQUc4K9tkE8A3YaVidAxPR1e58jOob9kcFjoc2sIkN4= X-Received: by 2002:a05:6512:20d:b0:4d5:ca43:7047 with SMTP id a13-20020a056512020d00b004d5ca437047mr6804593lfo.10.1678374007805; Thu, 09 Mar 2023 07:00:07 -0800 (PST) MIME-Version: 1.0 References: <20230217022646.99959-1-kito.cheng@sifive.com> In-Reply-To: From: Kito Cheng Date: Thu, 9 Mar 2023 22:59:56 +0800 Message-ID: Subject: Re: [PATCH] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1 To: Xi Ruoyao Cc: Palmer Dabbelt , libc-alpha@sourceware.org, joseph@codesourcery.com, jeffreyalaw@gmail.com, Darius Rad , christoph.muellner@vrull.eu, DJ Delorie , Andrew Waterman , Wilco Dijkstra Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Ruoyao: GCC isn't set that to -1, but clang/LLVM did, see https://github.com/llvm/llvm-project/issues/60781 and https://reviews.llvm.org/D121122 Seems like LLVM folks are consider to rever that, but even clang/LLVM revert that, the issue still there: should we treat indeterminable precision as evaluating value as long double? It's almost no benefit for those targets who have 128 bit long double type. On Thu, Mar 9, 2023 at 10:33=E2=80=AFPM Xi Ruoyao wrot= e: > > I'm wondering why the compiler will set __FLT_EVAL_METHOD__ to -1 in the > first place. On gcc91 (VisionFive v1 board) I get: > > xry111@gcc91:~$ echo __FLT_EVAL_METHOD__ | cpp > # 0 "" > # 0 "" > # 0 "" > # 1 "/usr/include/stdc-predef.h" 1 3 4 > # 0 "" 2 > # 1 "" > 0 > > On Thu, 2023-03-09 at 22:14 +0800, Kito Cheng via Libc-alpha wrote: > > ping > > > > > > On Sun, Feb 19, 2023 at 2:29=E2=80=AFAM Palmer Dabbelt > > 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__ =3D=3D -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.ht= ml > > > > > > > > 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=E2=80=99s 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__ =3D=3D -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 # RISC-V > > > > > > though we should have a global reviewed look at this now that it's > > > touching everything. > > -- > Xi Ruoyao > School of Aerospace Science and Technology, Xidian University