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 9CB163858D3C for ; Fri, 11 Nov 2022 19:25:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9CB163858D3C 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=1668194728; 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: in-reply-to:in-reply-to:references:references; bh=GJG/AGrLWU8CznScRYgpo6R0AK8FznBcZTNyYhsaHP8=; b=h3MU5d/Hl9iUHU01iw58poJH+6r30WzthNKhOtlKZilfu0bwVhoCvqNNlwR9SLAqcHg78N jmsao/ncG5oC7eGQCaMHNUDIjhYFDsuZd0WuDIo2Fhce9I2DZJ4FVYkvX2CmBRq5vnyHlF fMls6YrT0HMENZYY9xWGzTHxlxkVU9Y= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-403-q6E45oouNLmzT8nXucTzpw-1; Fri, 11 Nov 2022 14:25:26 -0500 X-MC-Unique: q6E45oouNLmzT8nXucTzpw-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-373569200ceso51959067b3.4 for ; Fri, 11 Nov 2022 11:25:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GJG/AGrLWU8CznScRYgpo6R0AK8FznBcZTNyYhsaHP8=; b=geBGUcFQI4/RIesh37RiGaWU8e0cEf0lVIHndDUmMQfctIMl+afzi856/ZsZ4iNujz T3Ym/ClfsUNO29kgUc1xb3JtCS59krhh/qAoDGWm+ZJIqj2aDPLzrik4iLOid5W2iC+Y aKGgXOi3HF7pO/fe/mdmn6rlO4MMSZ4btQ59RtEwP07aohw15+4FotGv6a/RqjlXrJ4x D6K+2271KBQ3Tpa9IktxiC3Brz2daTB7sTr6S0ApBFuhoD5i95cg6l7fwJAnL2N6RtNQ ICgHvdW1ZMChegbykM5PxW5XglxR3q7uPmGVQjSIR/2Q5sMFLWzXrLaRHBeb/eSZeu92 /Y4w== X-Gm-Message-State: ANoB5pkF3nu1e5CgsP3o7Q2QiAxWbQqu2bLMuOrFSS0+I5ks9oYlJ8Vw iKEQLrHqxl6IASQDvFxhqodKMlkW0F2AmBJjnkmEPRfFHdeLDlSNdwmo9/FL9m/RPhbw7LFHJ/a 7G91BFkctnWPmE//D2L/2SDgyh280Fiqgog== X-Received: by 2002:a81:d81:0:b0:369:2064:9762 with SMTP id 123-20020a810d81000000b0036920649762mr3409206ywn.154.1668194726304; Fri, 11 Nov 2022 11:25:26 -0800 (PST) X-Google-Smtp-Source: AA0mqf7xAXXVAQbSkSIlej1cDjMGJ6oy+1+yEHlBTvSgvjp6oA3zqC9OPHX3NYNfDQwZWqfvD55SOlRt9M4ibgBoNuM= X-Received: by 2002:a81:d81:0:b0:369:2064:9762 with SMTP id 123-20020a810d81000000b0036920649762mr3409195ywn.154.1668194726049; Fri, 11 Nov 2022 11:25:26 -0800 (PST) MIME-Version: 1.0 References: <20221111181147.278546-1-aldyh@redhat.com> In-Reply-To: <20221111181147.278546-1-aldyh@redhat.com> From: Aldy Hernandez Date: Fri, 11 Nov 2022 20:25:15 +0100 Message-ID: Subject: Re: [PATCH] [range-ops] Add ability to represent open intervals in frange. To: Jakub Jelinek Cc: GCC patches , Andrew MacLeod X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="000000000000100d5905ed36daf5" X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,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: --000000000000100d5905ed36daf5 Content-Type: text/plain; charset="UTF-8" Passes tests for all languages. Passes lapack tests. So.... ready to be installed unless you have any issues. Oh... I should write some tests.. Aldy On Fri, Nov 11, 2022, 19:11 Aldy Hernandez wrote: > Currently we represent < and > with a closed interval. So < 3.0 is > represented as [-INF, +3.0]. This means 3.0 is included in the range, > and though not ideal, is conservatively correct. Jakub has found a > couple cases where properly representing < and > would help > optimizations and tests, and this patch allows representing open > intervals with real_nextafter. > > There are a few caveats. > > First, we leave MODE_COMPOSITE_P types pessimistically as a closed > interval. > > Second, for -ffinite-math-only, real_nextafter will will saturate the > maximum representable number into +INF. However, this will still do > the right thing, as frange::set() will crop things appropriately. > > Finally, and most frustratingly, representing < and > -+0.0 is > problematic because we flush denormals to zero. Let me explain... > > real_nextafter(+0.0, +INF) gives 0x0.8p-148 as expected, but setting a > range to this value yields [+0.0, 0x0.8p-148] because of the flushing. > > On the other hand, real_nextafter(+0.0, -INF) (surprisingly) gives > -0.0.8p-148, but setting a range to that value yields [-0.0x8p-148, > -0.0]. I say surprising, because according to cppreference.com, > std::nextafter(+0.0, -INF) should give -0.0. But that's neither here > nor there because our flushing denormals to zero prevents us from even > representing ranges involving small values around 0.0. We ultimately > end up with ranges looking like this: > > > +0.0 => [+0.0, INF] > > -0.0 => [+0.0, INF] > < +0.0 => [-INF, -0.0] > < -0.0 => [-INF, -0.0] > > I suppose this is no worse off that what we had before with closed > intervals. One could even argue that we're better because we at least > have the right sign now ;-). > > All other (non-zero) values look sane. > > Lightly tested. > > Thoughts? > > gcc/ChangeLog: > > * range-op-float.cc (build_lt): Adjust with frange_nextafter > instead of default to a closed range. > (build_gt): Same. > --- > gcc/range-op-float.cc | 23 +++++++++++++++++++---- > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc > index 380142b4c14..402393097b2 100644 > --- a/gcc/range-op-float.cc > +++ b/gcc/range-op-float.cc > @@ -381,9 +381,17 @@ build_lt (frange &r, tree type, const frange &val) > r.set_undefined (); > return false; > } > - // We only support closed intervals. > + > REAL_VALUE_TYPE ninf = frange_val_min (type); > - r.set (type, ninf, val.upper_bound ()); > + REAL_VALUE_TYPE prev = val.upper_bound (); > + machine_mode mode = TYPE_MODE (type); > + // Default to the conservatively correct closed ranges for > + // MODE_COMPOSITE_P, otherwise use nextafter. Note that for > + // !HONOR_INFINITIES, nextafter will yield -INF, but frange::set() > + // will crop the range appropriately. > + if (!MODE_COMPOSITE_P (mode)) > + frange_nextafter (mode, prev, ninf); > + r.set (type, ninf, prev); > return true; > } > > @@ -424,9 +432,16 @@ build_gt (frange &r, tree type, const frange &val) > return false; > } > > - // We only support closed intervals. > REAL_VALUE_TYPE inf = frange_val_max (type); > - r.set (type, val.lower_bound (), inf); > + REAL_VALUE_TYPE next = val.lower_bound (); > + machine_mode mode = TYPE_MODE (type); > + // Default to the conservatively correct closed ranges for > + // MODE_COMPOSITE_P, otherwise use nextafter. Note that for > + // !HONOR_INFINITIES, nextafter will yield +INF, but frange::set() > + // will crop the range appropriately. > + if (!MODE_COMPOSITE_P (mode)) > + frange_nextafter (mode, next, inf); > + r.set (type, next, inf); > return true; > } > > -- > 2.38.1 > > --000000000000100d5905ed36daf5--