From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E51823858D1E for ; Fri, 11 Nov 2022 10:56:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E51823858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668164186; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=LPfBsxvnC0NLGSIwrtQ/xELrf7QFtP5OihflBSWEHsg=; b=EIdCvt5oBjDighgKQFLMLIpMc3T7qOuuVCcu/5MQ0nQf6BJIrz5ISRtyKzBqpAsshqwvO+ NwA/jb4Kqmg6Fr4KQnXvEd5Mis6Ps5Xh3KsMofJeN9cITHsqb/1jfXZfCD5UM6fMNgRCMh 9nXy7MsicDbeSA+f/BeKTUQIu4d5ZZQ= 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-624-r2hRdVr7NASobweAZfaTOA-1; Fri, 11 Nov 2022 05:56:17 -0500 X-MC-Unique: r2hRdVr7NASobweAZfaTOA-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9B423101A54E for ; Fri, 11 Nov 2022 10:56:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5B3A04B400F; Fri, 11 Nov 2022 10:56:17 +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 2ABAuFF33250211 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 11 Nov 2022 11:56:15 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2ABAuE0J3250210; Fri, 11 Nov 2022 11:56:14 +0100 Date: Fri, 11 Nov 2022 11:56:14 +0100 From: Jakub Jelinek To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] range-op: Cleanup floating point multiplication and division fold_range [PR107569] Message-ID: Reply-To: Jakub Jelinek References: <7304acea-b8bb-c930-546a-db6e3b3ff96b@redhat.com> <6dce0658-5f63-79cf-c588-66e37e1774da@redhat.com> MIME-Version: 1.0 In-Reply-To: <6dce0658-5f63-79cf-c588-66e37e1774da@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 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 List-Id: On Fri, Nov 11, 2022 at 11:12:01AM +0100, Aldy Hernandez wrote: > > --- gcc/range-op-float.cc.jj 2022-11-11 10:13:30.879410560 +0100 > > +++ gcc/range-op-float.cc 2022-11-11 10:55:57.602617289 +0100 > > @@ -1911,7 +1911,125 @@ class foperator_minus : public range_ope > > } fop_minus; > > -class foperator_mult : public range_operator_float > > +class foperator_mult_div_base : public range_operator_float > > +{ > > +protected: > > + // True if [lb, ub] is [+-0, +-0]. > > + static bool zero_p (const REAL_VALUE_TYPE &lb, > > + const REAL_VALUE_TYPE &ub) > > + { > > + return real_iszero (&lb) && real_iszero (&ub); > > + } > > + > > + // True if +0 or -0 is in [lb, ub] range. > > + static bool contains_zero_p (const REAL_VALUE_TYPE &lb, > > + const REAL_VALUE_TYPE &ub) > > + { > > + return (real_compare (LE_EXPR, &lb, &dconst0) > > + && real_compare (GE_EXPR, &ub, &dconst0)); > > + } > > + > > + // True if [lb, ub] is [-INF, -INF] or [+INF, +INF]. > > + static bool singleton_inf_p (const REAL_VALUE_TYPE &lb, > > + const REAL_VALUE_TYPE &ub) > > + { > > + return real_isinf (&lb) && real_isinf (&ub, real_isneg (&lb)); > > + } > > + > > + // Return -1 if binary op result must have sign bit set, > > + // 1 if binary op result must have sign bit clear, > > + // 0 otherwise. > > + // Sign bit of binary op result is exclusive or of the > > + // operand's sign bits. > > + static int signbit_known_p (const REAL_VALUE_TYPE &lh_lb, > > + const REAL_VALUE_TYPE &lh_ub, > > + const REAL_VALUE_TYPE &rh_lb, > > + const REAL_VALUE_TYPE &rh_ub) > > + { > > + if (real_isneg (&lh_lb) == real_isneg (&lh_ub) > > + && real_isneg (&rh_lb) == real_isneg (&rh_ub)) > > + { > > + if (real_isneg (&lh_lb) == real_isneg (&rh_ub)) > > + return 1; > > + else > > + return -1; > > + } > > + return 0; > > + } > > + > > + // Set [lb, ub] to [-0, -0], [-0, +0] or [+0, +0] depending on > > + // signbit_known. > > + static void zero_range (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, > > + int signbit_known) > > + { > > + ub = lb = dconst0; > > + if (signbit_known <= 0) > > + lb = real_value_negate (&dconst0); > > + if (signbit_known < 0) > > + ub = lb; > > + } > > + > > + // Set [lb, ub] to [-INF, -INF], [-INF, +INF] or [+INF, +INF] depending on > > + // signbit_known. > > + static void inf_range (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, > > + int signbit_known) > > + { > > + if (signbit_known > 0) > > + ub = lb = dconstinf; > > + else if (signbit_known < 0) > > + ub = lb = dconstninf; > > + else > > + { > > + lb = dconstninf; > > + ub = dconstinf; > > + } > > + } > > + > > + // Set [lb, ub] to [-INF, -0], [-INF, +INF] or [+0, +INF] depending on > > + // signbit_known. > > + static void zero_to_inf_range (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE &ub, > > + int signbit_known) > > + { > > + if (signbit_known > 0) > > + { > > + lb = dconst0; > > + ub = dconstinf; > > + } > > + else if (signbit_known < 0) > > + { > > + lb = dconstninf; > > + ub = real_value_negate (&dconst0); > > + } > > + else > > + { > > + lb = dconstninf; > > + ub = dconstinf; > > + } > > + } > > The above functions look like they could be useful outside of the mult/div > implementation. Perhaps put them in file scope, instead limiting it to > foperator_mult_div_base? Well, I didn't want to export them to everything and most of the file works on franges, not on REAL_VALUE_TYPE pairs. But sure, if there are other uses, it can be moved elsewhere. > > + static void zero_to_inf_range (REAL_VALUE_TYPE &lb, REAL_VALUE_TYPE > &ub, > > + int signbit_known) > > + { > > + if (signbit_known > 0) > > The rest of frange uses bool for a sign. Also, real_iszero, real_isinf, > real_inf, etc all use bool sign. Can you use a bool, or is there a reason > for the int? I need a tristate. signbit is known and clear (this happens when all the 4 bounds have the same sign), signbit is known and set (this happens when one operand has signbit clear and the other signbit set, or vice versa), or the state of the resulting signbit is unknown (at least one operand has some values in the range with clear and others with set signbit). Jakub