From patchwork Tue Mar 14 15:19:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kito Cheng X-Patchwork-Id: 66376 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C41CC38555A4 for ; Tue, 14 Mar 2023 15:20:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C41CC38555A4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678807229; bh=q1CT+8OIujHztDqbm9N569aFwu1R9LC4NaWRLSw9Efc=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=XxqLIbOIeI7ONaNLxuXpMliwpczGSKh+Y8FV+hhdzRCjmqXm41ujiov/52U2DD8vJ KTA7y97/wQjn0eL3buyv2rf3Rqk4usP+YSkx0Skg792oGYBs9xpfWjHVB0q9EUeybq Ep3RIOtJCx/a6OVhK6lxG10/zPjaPdsXyznkWHNs= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 4B1E13857C45 for ; Tue, 14 Mar 2023 15:19:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B1E13857C45 Received: by mail-pj1-x1032.google.com with SMTP id j3-20020a17090adc8300b0023d09aea4a6so6370793pjv.5 for ; Tue, 14 Mar 2023 08:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678807197; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=q1CT+8OIujHztDqbm9N569aFwu1R9LC4NaWRLSw9Efc=; b=BhFPLkef0ZDLTSeBlEjQvnGBRg2X/fOiNTDqhmp1rP/2rgrP/UNpzzwwZa1wTFJuu7 UDDH637z7KJF8nC9WsfN5T1v1PN/Ru0knwRplWdJ0OgmxycCP1KlSF86WPn1fDwJw8el 3+aVfapYewpJz/g+BalnWMrV35ae6qmxnuW0SL9jyFPkuaG/s7LFD7lMg0CnLBeiZbwE l+CUM70rRywsoYTSo+C1uMyre6DxfzU++H1aejHGW3i0HN/alepVKH3SZZDvrKqoB2ww X8KMXPnRL+ELP917y1tUcsigfpMlLp0zY7VOSuU7TXouSKGWNKy6yakbnPt9ZFBz4lDR djiQ== X-Gm-Message-State: AO0yUKUVoKJZq8Ipu2Dh5gYwOIv/WacvYkqOFDNkidaUw1a3PMU4FVBi UofwTJ+Jz6GYqt584NirXDfdn0l/hzdf4rNtW2tkUdwtFxlA+HuKPJ9avPpNagRLW+ZOSRNQaGT Iq78HmWgJBHK6JBnoU9LmGB6YPoceypOlCMUn7MohXrzHRnxWEI5qMAi5X0+278BvqrPk8TDoh0 lt95uXWA== X-Google-Smtp-Source: AK7set87O/zDC+oPVAjvW10dnC/CYOaqVsQo/fSDU4lW/8q9RYrwCSy53o5K2dlbi/r4uDXmcHhvlw== X-Received: by 2002:a17:903:22d2:b0:19c:d32a:befc with SMTP id y18-20020a17090322d200b0019cd32abefcmr42535728plg.15.1678807196465; Tue, 14 Mar 2023 08:19:56 -0700 (PDT) Received: from hsinchu02.internal.sifive.com (59-124-168-89.hinet-ip.hinet.net. [59.124.168.89]) by smtp.gmail.com with ESMTPSA id x89-20020a17090a6c6200b00230c8484fbfsm1827717pjj.55.2023.03.14.08.19.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Mar 2023 08:19:55 -0700 (PDT) To: libc-alpha@sourceware.org, joseph@codesourcery.com, palmer@rivosinc.com, jeffreyalaw@gmail.com, darius@bluespec.com, christoph.muellner@vrull.eu, dj@redhat.com, andrew@sifive.com, xry111@xry111.site, Wilco.Dijkstra@arm.com Cc: Kito Cheng Subject: [PATCH v2] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1 Date: Tue, 14 Mar 2023 23:19:48 +0800 Message-Id: <20230314151948.12892-1-kito.cheng@sifive.com> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 X-Spam-Status: No, score=-12.9 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Kito Cheng via Libc-alpha From: Kito Cheng Reply-To: Kito Cheng Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" __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 # RISC-V Reviewed-by: Wilco Dijkstra  --- v2 Changes: - Tweak comment. - Tweak commit log: Separating commit log, discussion and c99 spec reference. 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. 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 | 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