From patchwork Thu Sep 22 15:02:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 1681179 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: legolas.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=TRcOYhly; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4MYJSF2JGXz1yqL for ; Fri, 23 Sep 2022 01:03:08 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AA7AF3858017 for ; Thu, 22 Sep 2022 15:03:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA7AF3858017 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663858982; bh=Mt5ZJibgjV4S4zcPAxLjcnITUyAN53QyS+X6De4hasE=; h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=TRcOYhlyp9HC0cXDevRoxeHbrNsJGwVLXiaPEq/6FkguIPDVyD48OlLwC8/WFOyoL 1aj18Xn4420kJTxLdVK77K53KkbGIC4sEp+q/qGF0I3AzoJr1DU3clJ28D0a78hHBw MY4atnJ4/ktJ2ARxrihNsrqDZSGYrg8SQ7z0xW60= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 817C738582B2 for ; Thu, 22 Sep 2022 15:02:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 817C738582B2 Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-584-hG8Fli_OM5CjyczSCSj5LA-1; Thu, 22 Sep 2022 11:02:31 -0400 X-MC-Unique: hG8Fli_OM5CjyczSCSj5LA-1 Received: by mail-oi1-f198.google.com with SMTP id bl2-20020a056808308200b0035028763f44so4694540oib.19 for ; Thu, 22 Sep 2022 08:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=Mt5ZJibgjV4S4zcPAxLjcnITUyAN53QyS+X6De4hasE=; b=U3FVVrfH4bpeQwYBSUpsyB109d3W5etSmUy5MioQi26vSEExUlcpgOeE859O9wnxxI FETcKH/EvTzrasSq5lH6iOnx9AI6GGTf22mNsad6h8xEPZbhRPdywDhDK1nld8nMao2w q1YGRw2MXX0dyagGZNCqtZ14NqJDBVlJuiD12//XBcSUU7Ogm0FqN+uq8aWL4AWk1RFZ JXN06FdXWmmuWr6JvkZw2E3GFfNXtoiOKSaY5YMuBCh4E1+jtoyTmmRlgHPWCGhQ7icB a/Fl7Z8/ZLu5HVqyY+XHAPsBc4Yt+GUGl/tSKP69HLdjwKYc88EMLZk7RW65LBl/O1eq r2Nw== X-Gm-Message-State: ACrzQf2w8xUwclHJBGGHgTrMSziS4iFU9ECKsyNIqHmTzftsKlHHggT2 pCGk2pFP4MGWQRoCTBvvZb0fbXlGPilQRjc3veJzNzdWsqMYLgDmwgic3+qUY3E2BRNvtSoOm11 DAjDtGj6YM2j9ODC47gs9TVafjL1n1TN6Yg== X-Received: by 2002:a05:6870:160c:b0:12b:9663:67ca with SMTP id b12-20020a056870160c00b0012b966367camr8499606oae.36.1663858950720; Thu, 22 Sep 2022 08:02:30 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4N50qRjiIAc01uiz4X0Qp5u2DAlO0oLpODjm8BA5PzReSbLZpIq7lQovubt61Egz7j8t2Fdzk4zS8JTCBsJlI= X-Received: by 2002:a05:6870:160c:b0:12b:9663:67ca with SMTP id b12-20020a056870160c00b0012b966367camr8499568oae.36.1663858950310; Thu, 22 Sep 2022 08:02:30 -0700 (PDT) MIME-Version: 1.0 Date: Thu, 22 Sep 2022 17:02:19 +0200 Message-ID: Subject: TYPE_{MIN/MAX}_VALUE for floats? To: Richard Biener , Jakub Jelinek , gcc-patches , "MacLeod, Andrew" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Aldy Hernandez via Gcc-patches From: Aldy Hernandez Reply-To: Aldy Hernandez Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" It has always irritated me that we don't have TYPE_MIN_VALUE and TYPE_MAX_VALUE for floats (and for pointers for that matter). This means, we have to recalculate it ad-nauseum in vrp_val_min and vrp_val_max. I know we have dconstinf and dconstninf for floats, which we can just wrap around a TREE_REAL_CST, but it still seems like we should be more consistent here. If we know the endpoint for a type, we should cache it in it. Furthermore, just the way we're chopping off NANs in the frange::set() routine, we should be able to chop off things outside the min/max representable range, at least for -ffinite-math-only. For example, the endpoints to VR_VARYING for a float in -ffinite-math-only should be real_{min/max}_representable(), which REAL_VALUE_TYPE already provides. I am testing a patch to do this, but am unhappy that we have recalculate things. Is there a reason we can't store these in the type? I tried the naive attached approach, but I quickly ran into LTO woes: FAIL: gcc.c-torture/execute/ieee/20001122-1.c compilation, -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: 'verify_type' failed) $ ./xgcc -B./ a.c -O2 -flto -w lto1: error: type variant differs by TYPE_MAX_VALUE So I clearly don't know what I'm doing. Would folks be ok with filling TYPE_MIN_VALUE and friends for floats, and if so, could someone give me a hand here? What am I missing? Thanks. Aldy p.s. Now that we're onto this subject, in the distant future, I'd actually like to store a vrange in the tree type. I mean, they are first class citizens in the SSA name now, and we have a typeless way of storing ranges in GC space. Anywho, that's for the future, cause I like the pain... just wanted to gauge the temperature on that one as well. diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc index 88923c4136b..98f268d9f5a 100644 --- a/gcc/stor-layout.cc +++ b/gcc/stor-layout.cc @@ -43,6 +43,7 @@ along with GCC; see the file COPYING3. If not see #include "attribs.h" #include "debug.h" #include "calls.h" +#include "real.h" /* Data type for the expressions representing sizes of data types. It is the first integer type laid out. */ diff --git a/gcc/tree.cc b/gcc/tree.cc index 4165cbd7c3b..7a1fc6c4888 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -7620,6 +7620,31 @@ build_offset_type (tree basetype, tree type) return t; } +/* Create a floating point type with PRECISION. */ + +tree +build_float_type (unsigned precision) +{ + tree type = make_node (REAL_TYPE); + TYPE_PRECISION (type) = precision; + layout_type (type); + + if (flag_finite_math_only) + { + REAL_VALUE_TYPE min, max; + real_min_representable (&min, type); + real_max_representable (&max, type); + TYPE_MIN_VALUE (type) = build_real (type, min); + TYPE_MAX_VALUE (type) = build_real (type, max); + } + else + { + TYPE_MIN_VALUE (type) = build_real (type, dconstninf); + TYPE_MAX_VALUE (type) = build_real (type, dconstinf); + } + return type; +} + /* Create a complex type whose components are COMPONENT_TYPE. If NAMED is true, the type is given a TYPE_NAME. We do not always @@ -9427,17 +9452,9 @@ build_common_tree_nodes (bool signed_char) pointer_sized_int_node = build_nonstandard_integer_type (POINTER_SIZE, 1); - float_type_node = make_node (REAL_TYPE); - TYPE_PRECISION (float_type_node) = FLOAT_TYPE_SIZE; - layout_type (float_type_node); - - double_type_node = make_node (REAL_TYPE); - TYPE_PRECISION (double_type_node) = DOUBLE_TYPE_SIZE; - layout_type (double_type_node); - - long_double_type_node = make_node (REAL_TYPE); - TYPE_PRECISION (long_double_type_node) = LONG_DOUBLE_TYPE_SIZE; - layout_type (long_double_type_node); + float_type_node = build_float_type (FLOAT_TYPE_SIZE); + double_type_node = build_float_type (DOUBLE_TYPE_SIZE); + long_double_type_node = build_float_type (LONG_DOUBLE_TYPE_SIZE); for (i = 0; i < NUM_FLOATN_NX_TYPES; i++) { diff --git a/gcc/tree.h b/gcc/tree.h index 266e24a0563..b83fac17f1a 100644 --- a/gcc/tree.h +++ b/gcc/tree.h @@ -4729,6 +4729,7 @@ extern tree build_varargs_function_type_array (tree, int, tree *); extern tree build_method_type_directly (tree, tree, tree); extern tree build_method_type (tree, tree); extern tree build_offset_type (tree, tree); +extern tree build_float_type (unsigned); extern tree build_complex_type (tree, bool named = false); extern tree array_type_nelts (const_tree);