From patchwork Fri Mar 10 08:07:44 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 67264 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp743641wrd; Fri, 10 Mar 2023 00:08:42 -0800 (PST) X-Google-Smtp-Source: AK7set9eA15cIyTq/vMuKRgMW9ZThdZyAM3YhKguUepArP5xQOfXpzqs6K6p92m3N2YhP1CDnQdr X-Received: by 2002:a17:906:4bcd:b0:8b1:812f:2578 with SMTP id x13-20020a1709064bcd00b008b1812f2578mr22332760ejv.45.1678435722855; Fri, 10 Mar 2023 00:08:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678435722; cv=none; d=google.com; s=arc-20160816; b=RhrbKpF2YwmQIsSpXm7jJae6Fwt+X+9rnMf7dlSxhquy7tJbfuFVlc9zo8bcqT2XV6 71QN6F+7ktJO8xbhQlerZ9JQl35jMN9f+7yFqsllzUFhxWWiWsInFs6TXnGsoNkxqvjl mgsXCIzlnkPDbW3IxAnsDNG2kr56E6wJYhUKGE9+qYYofA/iagsKMjNid9sUqpoPYL7x 9zneulB1VILlIQZPTQUQ7pc0yLN6qI1aOBdI0P/UkJ2ft+GzSvRWPLrZiCjKN3hwGtRV dsh1oPg3lOF/H1H1Zlj42LQGkGesHt4SW5nJJSQKc15iYc9kXpqAOBrL8gdvOW/oC8bX +yPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:message-id:subject:cc:to:date :dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=0kD2epsvnVZsyBnD4r4KN9RYaGkClNPcXNEPH10TzSM=; b=Hitz/3MJKP3sEkBDVu2W5klCEBySDHq969ZLnN4Fgcl7SnejM+E1sL1NiUUTOqUYqk vIj1TwE/2ALKXw47hba5L41UuW+XwcH5soC8uP5h4UdhOad4SyUN9Y2YIB3oIF9qkedW GCLYoGCuXmyLLMaWS/x/47+bZG3X+A+QFvB+mh8r5vEJ8/RFZsJmLR5mYQtnKXB4Z8vX x0H63Rrg4m490TqLw3J3L0VWLzvZOvEqy/8LNyoldBHscD0SLK4dFhigqaMqZy+NTu4t V3yamQapODleO4+mGZStBfBp6eoxqiqRXPjpzEnA9J/cur6pyCvS/8Clkz+BHtCIwOrb CvYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=gNh3Atei; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id f26-20020a056402151a00b004ad747f0a8csi1915059edw.309.2023.03.10.00.08.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Mar 2023 00:08:42 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=gNh3Atei; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7CDBF38582BD for ; Fri, 10 Mar 2023 08:08:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7CDBF38582BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678435716; bh=0kD2epsvnVZsyBnD4r4KN9RYaGkClNPcXNEPH10TzSM=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=gNh3Atei14Yw0LoG2pLcnicONw4M2d4klhjrPPHf2ZMVYrCD0BebX6VNwxvaTLZsx bMYuOq/xWZg0pEsZE6+G3pCjnyHIOE1ubQBJUceNSPgbGufmEXMGhC3JnPduW7ZpGP HzEEP2rVNZg0U4+e5BcRsJL1HlpGVhBdE+B5wlM8= 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 551993858C54 for ; Fri, 10 Mar 2023 08:07:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 551993858C54 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-444-HK2B2vA-Pe2aaQyaAcM9ow-1; Fri, 10 Mar 2023 03:07:49 -0500 X-MC-Unique: HK2B2vA-Pe2aaQyaAcM9ow-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BFE1380D0F0; Fri, 10 Mar 2023 08:07:48 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7AA672026D4B; Fri, 10 Mar 2023 08:07:48 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 32A87jrB844218 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 09:07:46 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 32A87jal844217; Fri, 10 Mar 2023 09:07:45 +0100 Date: Fri, 10 Mar 2023 09:07:44 +0100 To: Richard Biener , Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] range-op-float: Fix up -ffinite-math-only range extension and don't extend into infinities [PR109008] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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: Jakub Jelinek via Gcc-patches From: Jakub Jelinek Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759967416911395410?= X-GMAIL-MSGID: =?utf-8?q?1759967416911395410?= Hi! The following patch does two things (both related to range extension around the boundaries). The first part (in the 2 real_isfinite blocks) is to make the ranges narrower when the old boundaries are minimum and/or maximum representable finite number. In that case frange_nextafter gives -Inf or +Inf, but then the resulting computed reverse range is very far from the actually needed range, usually extends up to infinity or could even result in NaNs. While infinities are really the next representable numbers in the corresponding mode, REAL_VALUE_TYPE is actually a type with wider range for exponent and 160 bit precision, so the patch instead uses nextafter number in a hypothetical floating point format with the same mantissa precision but wider range of exponents. This significantly improves the actual ranges of the reverse operations, while still making them conservatively correct. The second part is a fix for miscompilation of the new testcase below. For -ffinite-math-only, without this patch we extend the minimum and/or maximum representable finite number to -Inf or +Inf, with the patch to some number outside of the normal exponent range of the mode, but then we use set which canonicalizes it and turns the boundaries back to the minimum and/or maximum representable finite numbers, but because in say [__DBL_MAX__, __DBL_MAX__] = op1 + [__DBL_MAX__, __DBL_MAX__] op1 can be larger than 0, up to the largest number which rounds to even down back to __DBL_MAX__ and there are still no infinities involved, it needs to work even with -ffinite-math-only. So, we really need to widen the lhs range a little bit even in that case. The patch does that through temporarily clearing -ffinite-math-only, such that the value with infinities or the outside of bounds values passes the setting and verification (the VR_VARYING case is needed because we get ICEs otherwise, but when lhs is VR_VARYING in -ffast-math, i.e. minimum to maximum representable finite and both signs of NaN, then set does all we need, we don't need to or in a NaN range). We don't really later use the range in a way that would become a problem that it is wider than varying, we actually just perform maths on the two boundaries. As I said in the PR, this doesn't fix the !MODE_HAS_INFINITIES case, I believe we actually need to treat the boundary values as infinities in that case because they (probably) work like that, but it is unclear if it is just the reverse operation lhs widening that is a problem there, or whether it is a general problem. I have zero experience with floating points without infinities (PDP11, some ARM half type?, what else?). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2023-03-10 Jakub Jelinek PR tree-optimization/109008 * range-op-float.cc (float_widen_lhs_range): If lb is minimum representable finite number or ub is maximum representable finite number, instead of widening it to -inf or inf widen it to negative or positive 0x0.8p+(EMAX+1). Temporarily clear flag_finite_math_only when canonicalizing the widened range. * gcc.dg/pr109008.c: New test. Jakub --- gcc/range-op-float.cc.jj 2023-03-09 09:54:53.880453046 +0100 +++ gcc/range-op-float.cc 2023-03-09 20:52:07.456284507 +0100 @@ -2217,12 +2217,42 @@ float_widen_lhs_range (tree type, const REAL_VALUE_TYPE lb = lhs.lower_bound (); REAL_VALUE_TYPE ub = lhs.upper_bound (); if (real_isfinite (&lb)) - frange_nextafter (TYPE_MODE (type), lb, dconstninf); + { + frange_nextafter (TYPE_MODE (type), lb, dconstninf); + if (real_isinf (&lb)) + { + /* For -DBL_MAX, instead of -Inf use + nexttoward (-DBL_MAX, -LDBL_MAX) in a hypothetical + wider type with the same mantissa precision but larger + exponent range; it is outside of range of double values, + but makes it clear it is just one ulp larger rather than + infinite amount larger. */ + lb = dconstm1; + SET_REAL_EXP (&lb, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1); + } + } if (real_isfinite (&ub)) - frange_nextafter (TYPE_MODE (type), ub, dconstinf); + { + frange_nextafter (TYPE_MODE (type), ub, dconstinf); + if (real_isinf (&ub)) + { + /* For DBL_MAX similarly. */ + ub = dconst1; + SET_REAL_EXP (&ub, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1); + } + } + /* Temporarily disable -ffinite-math-only, so that frange::set doesn't + reduce the range back to real_min_representable (type) as lower bound + or real_max_representable (type) as upper bound. */ + bool save_flag_finite_math_only = flag_finite_math_only; + flag_finite_math_only = false; ret.set (type, lb, ub); - ret.clear_nan (); - ret.union_ (lhs); + if (lhs.kind () != VR_VARYING) + { + ret.clear_nan (); + ret.union_ (lhs); + } + flag_finite_math_only = save_flag_finite_math_only; return ret; } --- gcc/testsuite/gcc.dg/pr109008.c.jj 2023-03-09 12:25:11.507955698 +0100 +++ gcc/testsuite/gcc.dg/pr109008.c 2023-03-09 12:33:35.795598344 +0100 @@ -0,0 +1,26 @@ +/* PR tree-optimization/109008 */ +/* { dg-do run } */ +/* { dg-options "-O2 -ffinite-math-only -fexcess-precision=standard" } */ + +__attribute__((noipa)) double +foo (double eps) +{ + double d = __DBL_MAX__ + eps; + if (d == __DBL_MAX__) + if (eps > 16.0) + return eps; + return 0.0; +} + +int +main () +{ +#if __DBL_MANT_DIG__ == 53 && __DBL_MAX_EXP__ == 1024 && __DBL_MIN_EXP__ == -1021 \ + && __FLT_EVAL_METHOD__ == 0 + if (foo (0x0.8p+970) == 0.0) + __builtin_abort (); + if (foo (32.0) == 0.0) + __builtin_abort (); +#endif + return 0; +}