From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 93F003858D3C for ; Mon, 5 Sep 2022 09:01:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 93F003858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x631.google.com with SMTP id se27so15665481ejb.8 for ; Mon, 05 Sep 2022 02:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=sUcFn/Ho07ftGnoertkbTpaH34toTxs5/TQDoRWKW3Q=; b=mx9tOn9xTt7xqFKI3+27kL3YGI8/YxbJNuSq/wLKEB3brzVfiddqll7oXagoAAWlVv P2UTw5Pk508UHsDPgjWBk0xkKZwN9r/ICd8gzPV9RLH7PceOWz7T83luptpt6eevEcVG SdBsramWz6SkX4NSQZfTFCIsilGsgxZyMuB3vYNKxltyO0X1+EanP51Z6Bj7q8HP8wML XJXwRRxBU09KeCynq5RoPEeCK9CImx5kvuNad4ebg1TWeEPFjSVuFoKOj1E6Ue58JTvr 9wd9k58pvMlkwuE9jO77qNIW0zOD3sZv9mM1GuVVyHbu5fvNSFr+SQzLCPGYUbjSPfH7 tZow== 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; bh=sUcFn/Ho07ftGnoertkbTpaH34toTxs5/TQDoRWKW3Q=; b=leoqKoMen008ioENP2RZCtDVd+W4Dg5BNPKV0mbwQWfEpYYVkg2ovOVdT/8tpHWeqE vgMA4q4dK7JCU8Xfk4hEfJq68qJxecxG5s8RbxtbbzegdRahRlcw3MRKVDfchISIPg5U e1bsSLMLgXqCG05uZNfIXPrm1L7u/8/EeljnHkgekAehycIvbD7nPHzOYkXBoWJ5WCG8 2gHgINgZkHTgpNL2hNcQqp9/HKntQD7gLrpfh7wlQZTp+Y5TOeunTVjd3AF2ab0k2YsR WQuxOWB3G0vd+s9XBRQg58/rl4xGjTLUL3zbpKigabLnJGlpn7lySbdwDATqaBttxpWO S5Rw== X-Gm-Message-State: ACgBeo08l5otAqW3jrqt3sAr581cTV+SdSZCupw8gYjEsDuVJ/VKqufp KL01+1L+WlWBivOL1SfAs7zbUBmPJJknKQYeAsU= X-Google-Smtp-Source: AA6agR79+PlDvQlaeWsehSuewCrsMBdBll8nFrwNa4/1Sbf11okVeupbF44qk+42IF5WLBDAX/46aJMP+6TNGJnc0/k= X-Received: by 2002:a17:906:5d16:b0:74c:32ce:208b with SMTP id g22-20020a1709065d1600b0074c32ce208bmr11845669ejt.594.1662368466193; Mon, 05 Sep 2022 02:01:06 -0700 (PDT) MIME-Version: 1.0 References: <20220905062301.3240191-1-aldyh@redhat.com> In-Reply-To: <20220905062301.3240191-1-aldyh@redhat.com> From: Richard Biener Date: Mon, 5 Sep 2022 11:00:54 +0200 Message-ID: Subject: Re: [COMMITTED] Be even more conservative in intersection of NANs. To: Aldy Hernandez Cc: GCC patches , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches wrote: > > Intersecting two ranges where one is a NAN is keeping the sign bit of > the NAN range. This is not correct as the sign bits may not match. > > I think the only time we're absolutely sure about the intersection of > a NAN and something else, is when both are a NAN with exactly the same > properties (sign bit). If we're intersecting two NANs of differing > sign, we can decide later whether that's undefined or just a NAN with > no known sign. For now I've done the latter. > > I'm still mentally working on intersections involving NANs, especially > if we want to keep track of signbits. For now, let's be extra careful > and only do things we're absolutely sure about. > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5] > with the posibility of NAN, to a NAN, but I'm not 100% sure. The intersection of [NAN, NAN] and [3, 5] is empty. The intersection of [NAN, NAN] and VARYING is [NAN, NAN]. Not sure why you think NAN is somehow special? I suppose that [NAN, NAN] is actually implemented as ][ U NAN (empty range plus aside NaN bit) Richard. > As I've > said before, setting varying is always a safe choice, because it means > we know nothing and ranger won't attempt to optimize anything. > > gcc/ChangeLog: > > * value-range.cc (early_nan_resolve): Remove. > (frange::intersect): Handle NANs. > --- > gcc/value-range.cc | 35 ++++++++++++++++------------------- > 1 file changed, 16 insertions(+), 19 deletions(-) > > diff --git a/gcc/value-range.cc b/gcc/value-range.cc > index c9f42fe272c..9c561415971 100644 > --- a/gcc/value-range.cc > +++ b/gcc/value-range.cc > @@ -444,24 +444,6 @@ frange::normalize_kind () > return false; > } > > -// If both operands are definitely NAN, do nothing as they combine > -// perfectly. If OTOH, only one is a NAN, set R to VARYING as they > -// can't be neither unioned nor intersected. Return TRUE if we > -// changed anything. > - > -static inline bool > -early_nan_resolve (frange &r, const frange &other) > -{ > - gcc_checking_assert (r.get_nan ().yes_p () || other.get_nan ().yes_p ()); > - > - // There's nothing to do for both NANs. > - if (r.get_nan ().yes_p () == other.get_nan ().yes_p ()) > - return false; > - // ?? Perhaps the intersection of a NAN and anything is a NAN ??. > - r.set_varying (r.type ()); > - return true; > -} > - > bool > frange::union_ (const vrange &v) > { > @@ -532,8 +514,23 @@ frange::intersect (const vrange &v) > *this = r; > return true; > } > + > + // If two NANs are not exactly the same, drop to an unknown NAN, > + // otherwise there's nothing to do. > + if (get_nan ().yes_p () && r.get_nan ().yes_p ()) > + { > + if (m_props == r.m_props) > + return false; > + > + *this = frange_nan (m_type); > + return true; > + } > + // ?? Perhaps the intersection of a NAN and anything is a NAN ??. > if (get_nan ().yes_p () || r.get_nan ().yes_p ()) > - return early_nan_resolve (*this, r); > + { > + set_varying (m_type); > + return true; > + } > > bool changed = m_props.intersect (r.m_props); > > -- > 2.37.1 >