From patchwork Fri Feb 17 02:26:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kito Cheng X-Patchwork-Id: 65146 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 F29AE3857835 for ; Fri, 17 Feb 2023 02:27:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F29AE3857835 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676600843; bh=lgmHgCkPpiqKpLGpZ6PYZbU4J8EcYiYgVpCsuLCxwLU=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=gq3yWIedTE0wEEdbHWFbAEQlwxBmr5nDdZSOmgfL2TmloLDi70hQj7xNxkdrJvGFh 7AnyWouyQN4HroOTDuJmG17+F/f9IlVs9JPYP+TZJt7xljvNAUxLqTA5EGaH4N87pF tEsXgWfIb2+vVmRLHR8pPIgnZTkYJOxC8dcETm1U= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by sourceware.org (Postfix) with ESMTPS id 63AF73858C78 for ; Fri, 17 Feb 2023 02:26:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63AF73858C78 Received: by mail-pj1-x102a.google.com with SMTP id k24so3844623pji.2 for ; Thu, 16 Feb 2023 18:26:58 -0800 (PST) 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:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lgmHgCkPpiqKpLGpZ6PYZbU4J8EcYiYgVpCsuLCxwLU=; b=t68nyCuO2ggZyoQ9fekz8vY1xf5K7uBw3mWjlbHsot1X4oU+u8K/MwRWUBlsTasSvc G/ylMqSAWqxR0VW4B2JXKKzZJoH03lfJo7r5ylP80W9tAV5rS3UulLRz8HYt11OR4fin sQC8TFC2VQWdi6fKQ8xTxPtXZtjIBhV9BM6FqQmWHyNtoDjdaUGlkVrZtmqSz7fSMe0e d7tEu9auRWGkdZJqyKz4GQVaVqQol8r66Xsk7a/BTzofCE1Wp3wYhUqa61gyBhoFTMRj zro21P740UZPq9iSdZN/ghUSFcEolTNmVMoRiU5NvT3uwz+Ptd3eSVF8xRsbfsFHqoCn kkbw== X-Gm-Message-State: AO0yUKXwC2QWQp/fVLGiuWfCcRZmr/4hyFPi/xhIuEqjquIGlqn/nayA g3cE53ktK9/7lpUnNfLD2ejGNo44/aPEwAh3kmE75DrPe5NeWqvGLzY4dt1jTGkU1LoSGqcOND3 9Gg7JkESYetoAaKH8qQTw5OWzA6yRMEwwylWrDet43hKlxjHeitMGF6hAlS0H5ULesxTrMG/sz5 X0qh8= X-Google-Smtp-Source: AK7set9Y3uNALUBA4NRNhm0COjpZZWvkuSTreWowaAhnLcCoKVVuILE9YguK+GG/TGM1ovZsPCJ3Ow== X-Received: by 2002:a17:902:d2cc:b0:19a:98e8:50d1 with SMTP id n12-20020a170902d2cc00b0019a98e850d1mr10080008plc.34.1676600814861; Thu, 16 Feb 2023 18:26:54 -0800 (PST) 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 jk6-20020a170903330600b0019a96a6543esm1953134plb.184.2023.02.16.18.26.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Feb 2023 18:26:54 -0800 (PST) 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 Cc: Kito Cheng Subject: [PATCH] Remap __GLIBC_FLT_EVAL_METHOD to 0 if __FLT_EVAL_METHOD__ is -1 Date: Fri, 17 Feb 2023 10:26:46 +0800 Message-Id: <20230217022646.99959-1-kito.cheng@sifive.com> X-Mailer: git-send-email 2.37.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" --- 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. Acked-by: Palmer Dabbelt # RISC-V --- __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