From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 9C7253858D32 for ; Sat, 18 Feb 2023 18:29:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C7253858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-pl1-x629.google.com with SMTP id 19so1244910plo.7 for ; Sat, 18 Feb 2023 10:29:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=Sc5nGSwK5s0CHYYF5Kvuvh5RTpIR2FQfanuVWmBHAxg=; b=ldA0hwOzRqSkDtyqkc5OFF8MM9+HNtnVZfH76rF3LkV8Kx4tag57XGTp4X+kvGtm93 TiO/rFetCFKsGw2MuGkTA3JaQ4Txe+F/7wPa/PBbZD77wS2wnGHVNT1AB2JpMhw0jjrS hjoVglXCedJfKRcxzk9lDDme+mrwvG7ghmzZuHWjAvTCaOaE3xhyaj9CLSz0dPVZU7I3 R4JAP7bf8alm3oMsQdJtzYs8e2bK7OBTL88K1pOWWQWNbTsRofbBN9afLLvRxwk5iZdu NG05TkFDn4fm8rg1yysKDaI8/g+iwoocsEYmGedgjF3LA4HoGXBfUzWUXx90lPmYL0ll zcQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Sc5nGSwK5s0CHYYF5Kvuvh5RTpIR2FQfanuVWmBHAxg=; b=cbUhkzb2B7Ft8Oht8OVtixk1aOaWY2v50fOQ0kUCXRV08ooM5FwdeGb4X7yIb+VHGs 6p07lSXaAmb7ar+vGrw8ryBVOg67UQCQ1Etu4SmWKVaF3BNkeC9RqsauxWrfAlqr2+KE qYGkZk2DM8srG5MFRsRTpSf6YLjor/nFq8o/fGoTQz4/OhcB8qblOQATQXxgIRRNr4zN 4RyLWnNZ7EG3Sr4YlErnhXhzB6f0OmvhPyfKOlmqgIIHnSpoPH5P3bMv3s7jKBvJwo4r VhK5aAsLqeK8fFZ6dLpvzdeANYxQ4AqPTvSOvEZSLtnQIR8PQIx2n/YDd+lDw0XAMmnm c+FQ== X-Gm-Message-State: AO0yUKXGfXIxuSYpzfV9nJSWHpge4ErDQEkW5yGkF6ojLr/MpDaTE+mD iuJr8W0nPsDG4jSx5y36TeOEa2ObBI2JTFmX X-Google-Smtp-Source: AK7set9m18Hd2HtF+PH6fpTCbkJv1YYOmrcBYOo4ifTzPuMLYrSCs88yJDC4e9ufy/xgy1kYURCI9A== X-Received: by 2002:a05:6a20:7a8a:b0:c7:3b5f:d543 with SMTP id u10-20020a056a207a8a00b000c73b5fd543mr8215395pzh.49.1676744975088; Sat, 18 Feb 2023 10:29:35 -0800 (PST) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id k133-20020a633d8b000000b004fb8732a2f9sm4503821pga.88.2023.02.18.10.29.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Feb 2023 10:29:34 -0800 (PST) Date: Sat, 18 Feb 2023 10:29:34 -0800 (PST) X-Google-Original-Date: Sat, 18 Feb 2023 10:28:49 PST (-0800) Subject: Re: [PATCH] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1 In-Reply-To: <20230217022646.99959-1-kito.cheng@sifive.com> CC: libc-alpha@sourceware.org, joseph@codesourcery.com, jeffreyalaw@gmail.com, Darius Rad , christoph.muellner@vrull.eu, DJ Delorie , Andrew Waterman , kito.cheng@sifive.com From: Palmer Dabbelt To: kito.cheng@sifive.com Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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: 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 # RISC-V though we should have a global reviewed look at this now that it's touching everything.