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 570393835556 for ; Wed, 7 Dec 2022 15:21:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 570393835556 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=1670426476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=100jxKuIzNLUpA6wbJVbIhz3wgwBNDU4hfL4KB0Q6Uk=; b=ArDkKivmZ/gdatBaXOV3sUVoKPHScjWr/5EM4Gzua4FChLWDBEpYApUlq1Wd1ner9bsYZ1 oq0GPlfmWhXkGWxuc0ydahCgCrE5loJx/Q9KbQ33Pdt2kW0eh45asCgK4x67uEu5HlG7Dw 0lEBNKpvrcpU13JvQrOBEEuWSQyd8PQ= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-571-YYSQqiOpNaCC1RFuRrD8sw-1; Wed, 07 Dec 2022 10:21:14 -0500 X-MC-Unique: YYSQqiOpNaCC1RFuRrD8sw-1 Received: by mail-wr1-f72.google.com with SMTP id d4-20020adfa404000000b002421ca8cb07so4269687wra.2 for ; Wed, 07 Dec 2022 07:21:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=100jxKuIzNLUpA6wbJVbIhz3wgwBNDU4hfL4KB0Q6Uk=; b=294oJoVXqRVgtIT64B8lrFyKMu8K0dSpiV0P9R0LUpzUJPNMbTq2g1RFSsjMS+fuH4 IqIJ+kc5kbpAp3e3wuEAOT33YXeM+yVwBGpNR+wGKBhCameozVCoXLoZmaBxs64XbIY7 fF39UL6akPVgcoezyuntDxch6FKhxYoeplHMJbM2r78Xzc2zXL4bvzEhvq4cPjIb4g+m fhYWCge/ldzeJx4c2yYjXsg4TlkyIGlTa2E2G7Adl6hbBeg4oHDm0IbHf+NaXCu/mcZc 9U3Pdc84pBaSxA+nI1sil62DEFU6f1AR8f/1pHq+K0XfSclNHVuPyeWMmSb3+Yqnz0Bf yVCQ== X-Gm-Message-State: ANoB5plYWN2KwSPkGsqdfh6xK6iNHP6koNV4ACt5dWPIHyPgBgX2GohZ c+dTorIUVjX3nJwjpD7I8ShNBTO/b6KvETvYqLIp4gWS6tTepZkcGq4qFTP4wokPPanY44Kzq+f vBeYLDbGgmKg25tVz2Q== X-Received: by 2002:a5d:5d0b:0:b0:23a:5a31:29f5 with SMTP id ch11-20020a5d5d0b000000b0023a5a3129f5mr461169wrb.23.1670426472906; Wed, 07 Dec 2022 07:21:12 -0800 (PST) X-Google-Smtp-Source: AA0mqf6G6ly/kteM1/6vmlILUt5LOYh11kxOxwVa8tAoPjbIR3nrAnjrlZjgShdF4mOUyucDCb1vTw== X-Received: by 2002:a5d:5d0b:0:b0:23a:5a31:29f5 with SMTP id ch11-20020a5d5d0b000000b0023a5a3129f5mr461163wrb.23.1670426472563; Wed, 07 Dec 2022 07:21:12 -0800 (PST) Received: from [192.168.86.37] (128.red-81-33-16.staticip.rima-tde.net. [81.33.16.128]) by smtp.gmail.com with ESMTPSA id b4-20020a5d45c4000000b00242209dd1ffsm19642872wrs.41.2022.12.07.07.21.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Dec 2022 07:21:11 -0800 (PST) Message-ID: <851fe74e-e4da-7151-247d-41da27628b4e@redhat.com> Date: Wed, 7 Dec 2022 16:21:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] range-op-float: frange_arithmetic tweaks for MODE_COMPOSITE_P To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Andrew MacLeod References: From: Aldy Hernandez In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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 12/7/22 13:10, Jakub Jelinek wrote: > Hi! > > As mentioned in PR107967, ibm-ldouble-format documents that > +- has 1ulp accuracy, * 2ulps and / 3ulps. > So, even if the result is exact, we need to widen the range a little bit. > > The following patch does that. I just wonder what it means for reverse > division (the op1_range case), which we implement through multiplication, > when division has 3ulps error and multiplication just 2ulps. In any case, > this format is a mess and for non-default rounding modes can't be trusted > at all, instead of +inf or something close to it it happily computes -inf. > > 2022-12-07 Jakub Jelinek > > * range-op-float.cc (frange_arithmetic): For mode_composite, > on top of rounding in the right direction accept extra 1ulp > error for PLUS/MINUS_EXPR, extra 2ulps error for MULT_EXPR > and extra 3ulps error for RDIV_EXPR. > > --- gcc/range-op-float.cc.jj 2022-12-07 12:46:01.536123757 +0100 > +++ gcc/range-op-float.cc 2022-12-07 12:50:40.812085139 +0100 > @@ -344,22 +344,70 @@ frange_arithmetic (enum tree_code code, > } > } > } > - if (round && (inexact || !real_identical (&result, &value))) > + if (!inexact && !real_identical (&result, &value)) > + inexact = true; > + if (round && (inexact || mode_composite)) > { > if (mode_composite) > { > - if (real_isdenormal (&result, mode) > - || real_iszero (&result)) > + if (real_isdenormal (&result, mode) || real_iszero (&result)) > { > // IBM extended denormals only have DFmode precision. > REAL_VALUE_TYPE tmp; > real_convert (&tmp, DFmode, &value); > - frange_nextafter (DFmode, tmp, inf); > + if (inexact) > + frange_nextafter (DFmode, tmp, inf); > + 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... > + } > real_convert (&result, mode, &tmp); > return; > } > } > - frange_nextafter (mode, result, inf); > + if (inexact) > + frange_nextafter (mode, result, inf); > + if (mode_composite) > + 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 polluting what was a rather clean function. Would it be possible to abstract this into an inline function, and then we could do: if (mode_composite) frange_composite_nextafter (...); else frange_nextafter (...); or perhaps abstract the whole nextafter in frange_arithmetic into: frange_arithmetic_nextafter () { if (mode_composite) { do ugly stuff } else frange_nextafter (...) } I'm most worried about maintainability, not correctness here, cause you obviously know what you're doing ;-). Aldy > } > } > > > Jakub >