From patchwork Fri Mar 10 08:12:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 66203 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 81CB4385843E for ; Fri, 10 Mar 2023 08:13:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 81CB4385843E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678436021; bh=ZzzQnnGL0oDeOCjoUdlpMP8kZbU5hxVTV9pDkzRJQD8=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=B0L//7/yJGVHXmP/zxbQGbgz+9tpNvV5+Yi/dT1CnnAiZXt+fssEzFXYyW4T5Kd7Q PX0c+96OgSG9sZJM+rNP48Qnr/092EDAV9xcDKrya1ENo4ulfkkv+5iycYW0BXCL1k zBrI4mBLGd1jhW+EuaIZx/ai2XUkTXHDe4ZquP/M= 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.129.124]) by sourceware.org (Postfix) with ESMTPS id 80932385842B for ; Fri, 10 Mar 2023 08:12:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 80932385842B Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-367-F9Qe5uAQO9uGPuk3mzGYCQ-1; Fri, 10 Mar 2023 03:12:41 -0500 X-MC-Unique: F9Qe5uAQO9uGPuk3mzGYCQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0979D3C0F199; Fri, 10 Mar 2023 08:12:41 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C1C1DC15BA0; Fri, 10 Mar 2023 08:12:40 +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 32A8CcUf844246 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 10 Mar 2023 09:12:38 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 32A8CbAE844245; Fri, 10 Mar 2023 09:12:37 +0100 Date: Fri, 10 Mar 2023 09:12:37 +0100 To: Richard Biener , Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] range-op-float: Extend lhs by 0.5ulp rather than 1ulp if not -frounding-math [PR109008] Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.7 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+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! This patch, incremental to the just posted one, improves the reverse operation ranges significantly by widening just by 0.5ulp in each direction rather than 1ulp. Again, REAL_VALUE_TYPE has both wider exponent range and wider mantissa precision (160 bits) than any supported type, this patch uses the latter property. The patch doesn't do it if -frounding-math, because then the rounding can be +-1ulp in each direction depending on the rounding mode which we don't know, or for IBM double double because that type is just weird and we can't trust in sane properties. I've performed testing of these 2 patches on 300000 random tests as with yesterday's patch, exact numbers are in the PR, but I see very significant improvement in the precision of the ranges while keeping it conservatively correct. 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 not -frounding-math and not IBM double double format, extend lhs range just by 0.5ulp rather than 1ulp in each direction. Jakub --- gcc/range-op-float.cc.jj 2023-03-09 12:13:57.189790814 +0100 +++ gcc/range-op-float.cc 2023-03-09 13:12:05.248873234 +0100 @@ -2205,8 +2205,8 @@ zero_to_inf_range (REAL_VALUE_TYPE &lb, [1., 1.] = op1 + [1., 1.]. op1's range is not [0., 0.], but [-0x1.0p-54, 0x1.0p-53] (when not -frounding-math), any value for which adding 1. to it results in 1. after rounding to nearest. - So, for op1_range/op2_range extend the lhs range by 1ulp in each - direction. See PR109008 for more details. */ + So, for op1_range/op2_range extend the lhs range by 1ulp (or 0.5ulp) + in each direction. See PR109008 for more details. */ static frange float_widen_lhs_range (tree type, const frange &lhs) @@ -2230,6 +2230,14 @@ float_widen_lhs_range (tree type, const lb = dconstm1; SET_REAL_EXP (&lb, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1); } + if (!flag_rounding_math && !MODE_COMPOSITE_P (TYPE_MODE (type))) + { + /* If not -frounding-math nor IBM double double, actually widen + just by 0.5ulp rather than 1ulp. */ + REAL_VALUE_TYPE tem; + real_arithmetic (&tem, PLUS_EXPR, &lhs.lower_bound (), &lb); + real_arithmetic (&lb, RDIV_EXPR, &tem, &dconst2); + } } if (real_isfinite (&ub)) { @@ -2240,6 +2248,14 @@ float_widen_lhs_range (tree type, const ub = dconst1; SET_REAL_EXP (&ub, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1); } + if (!flag_rounding_math && !MODE_COMPOSITE_P (TYPE_MODE (type))) + { + /* If not -frounding-math nor IBM double double, actually widen + just by 0.5ulp rather than 1ulp. */ + REAL_VALUE_TYPE tem; + real_arithmetic (&tem, PLUS_EXPR, &lhs.upper_bound (), &ub); + real_arithmetic (&ub, RDIV_EXPR, &tem, &dconst2); + } } /* Temporarily disable -ffinite-math-only, so that frange::set doesn't reduce the range back to real_min_representable (type) as lower bound