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.129.124]) by sourceware.org (Postfix) with ESMTPS id 973E33834C18 for ; Wed, 7 Dec 2022 15:31:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 973E33834C18 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=1670427105; 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=uzREL8Sqw0+If2cVPzloDZsbIG90BDTfTDE3TrEom98=; b=MGQpcdI6S2dnvbafAaJrhcswfm2eRf1CaGVACBhQSsQRg82kFOx2pR6YiV55sHg/1QPDO4 71Kq2FTCTQuzeAAktlm8Hx1zRKTj5MGt9tNtncRBZxsNrbJ7tGX6YGB2hLkX80x3oJUkG4 SAW85oA325Z0+HA6ZE/6GSCEmykQQc4= 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-163-BP1Rsu8aNfOG7_-icUXK9w-1; Wed, 07 Dec 2022 10:31:43 -0500 X-MC-Unique: BP1Rsu8aNfOG7_-icUXK9w-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A86FC181B200 for ; Wed, 7 Dec 2022 15:31:42 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5270D1121314; Wed, 7 Dec 2022 15:31:41 +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 2B7FVE7r096084 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 7 Dec 2022 16:31:15 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2B7FVEjp096083; Wed, 7 Dec 2022 16:31:14 +0100 Date: Wed, 7 Dec 2022 16:31:13 +0100 From: Jakub Jelinek To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org, Andrew MacLeod Subject: Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P Message-ID: Reply-To: Jakub Jelinek References: <851fe74e-e4da-7151-247d-41da27628b4e@redhat.com> MIME-Version: 1.0 In-Reply-To: <851fe74e-e4da-7151-247d-41da27628b4e@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 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 Wed, Dec 07, 2022 at 04:21:09PM +0100, Aldy Hernandez wrote: > On 12/7/22 13:10, Jakub Jelinek wrote: > > + switch (code) > > + { > > + case PLUS_EXPR: > > + case MINUS_EXPR: > > + // ibm-ldouble-format documents 1ulp for + and -. > > + frange_nextafter (DFmode, tmp, inf); > > + break; > > + case MULT_EXPR: > > + // ibm-ldouble-format documents 2ulps for *. > > + frange_nextafter (DFmode, tmp, inf); > > + frange_nextafter (DFmode, tmp, inf); > > + break; > > + case RDIV_EXPR: > > + // ibm-ldouble-format documents 3ulps for /. > > + frange_nextafter (DFmode, tmp, inf); > > + frange_nextafter (DFmode, tmp, inf); > > + frange_nextafter (DFmode, tmp, inf); > > + break; > > + default: > > + if (!inexact) > > + return; > > + break; > > It looks like this chunk... > > > > + switch (code) > > + { > > + case PLUS_EXPR: > > + case MINUS_EXPR: > > + // ibm-ldouble-format documents 1ulp for + and -. > > + frange_nextafter (mode, result, inf); > > + break; > > + case MULT_EXPR: > > + // ibm-ldouble-format documents 2ulps for *. > > + frange_nextafter (mode, result, inf); > > + frange_nextafter (mode, result, inf); > > + break; > > + case RDIV_EXPR: > > + // ibm-ldouble-format documents 3ulps for /. > > + frange_nextafter (mode, result, inf); > > + frange_nextafter (mode, result, inf); > > + frange_nextafter (mode, result, inf); > > + break; > > + default: > > + break; > > + } > > ...is the same as this chunk. Plus, all this mode composite stuff is It is not the same, there is the DFmode, tmp vs. mode, result difference. But sure, we could either add an inline function which for (code, mode, result, inf) set of options (or (code, DFmode, tmp, inf)) do those 0, 1, 2, 3 frange_nextafter calls (and return bool if it did any - there is also the if (!inexact) return; case), or as you suggest perhaps change frange_nextafter to handle MODE_COMPOSITE_P differently and do there if (mode_composite && (real_isdenormal (&result, mode) || real_iszero (&result))) { // IBM extended denormals only have DFmode precision. REAL_VALUE_TYPE tmp; real_convert (&tmp, DFmode, &result); frange_nextafter (DFmode, tmp, inf); real_convert (&result, mode, &tmp); } else frange_nextafter (mode, result, inf); Though, that somewhat changes behavior, it will convert to DFmode and back for every nextafter rather than just once (just slower compile time), but also right now we start from value rather than result. So, perhaps a combination of that, change frange_nextafter to do the above and change frange_arithmetic for the initial inexact rounding only to do it by hand using range_nextafter and starting from value. Anyway, this patch is far less important than the previous one... Jakub