From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 16E493857C69 for ; Mon, 5 Sep 2022 09:53:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 16E493857C69 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-x636.google.com with SMTP id nc14so15956415ejc.4 for ; Mon, 05 Sep 2022 02:53:24 -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=J6BNutwgMycp0VgdSxhk7ChylDSiNdNwiJRFCWBspEo=; b=LVvXDIkXZne8XJhsig8/eD78Ppq7tR1xbFFjBoo/uUVfIpgk7BGEP2a7PjbHVce6CL AdwSvHFNlN7lli3gPXzbd7t6YbdcLeqdeypSoNaw009jpT3fgJcHwBdrfL3UfPNhMYb+ SvM3CzU/0XRBPRhXzKeFRr3ivKgUXS8fcZetklfZq0k+cqjhFqdrTFru/waU2/GfH9nz khNSiEtUxbMp2gwy6zgp59s7znvBqvRo3KnYGJSin7pmTwxHmsw86U5SC71Hz2h/89yt 7s0GbirEStb3SHObuYdk29Pv72cflu6xQB2itSMVKL+IYqjytm6u1iietsSpLiDEsWkt Pq7Q== 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=J6BNutwgMycp0VgdSxhk7ChylDSiNdNwiJRFCWBspEo=; b=ER0Z1VpRO2txUnLWwCPOHfzkax+44z6yBkcJRn1AgA3VmPy4wfayIK2tT6OFDrqM/Q vcDnJNyffRPh/vuhTtNLyxS7WIxQOcYv04fWpjFuS/gqQomCLNFnUkIa3l9foGUUDica scfLLP5zU8bt7nq9dNh39R0+Ahe3IISwKETFId9sapYBa1LkwoPHCOTCMFwXWvMDz8Qx nmWHIeCFPIVO2kl7tKzpX/e5g8zjbYmw/WYdrfxo/eB+O/JcaUrxwlSiXqDW7tLyZ2E+ SA/k9SPThmtw1HtZl0JL6bmYMQBAePwSWdViO2+Yiveeqgt/BwtivX2coh0iW/JUapwQ P0XA== X-Gm-Message-State: ACgBeo3XI+BXeXPNB7ZDVT5voRrSZAgTmSzHAtrChMXisabgWveTdh+k 0/Q2fB/H8G6jC7Wlpuxn/WexFQmg7RcRjx861UU= X-Google-Smtp-Source: AA6agR7z/q/k6SDHea9mvABLRTSTjmM1Hgyw60IhXRI54sOqWG9EAVLixrQI95eIyNdGOXuc/oUXaPwG9kgqpQaxoK8= X-Received: by 2002:a17:907:3e12:b0:738:fd2f:df80 with SMTP id hp18-20020a1709073e1200b00738fd2fdf80mr36765031ejc.29.1662371602775; Mon, 05 Sep 2022 02:53:22 -0700 (PDT) MIME-Version: 1.0 References: <20220905062301.3240191-1-aldyh@redhat.com> In-Reply-To: From: Richard Biener Date: Mon, 5 Sep 2022 11:53:10 +0200 Message-ID: Subject: Re: [COMMITTED] Be even more conservative in intersection of NANs. To: Aldy Hernandez Cc: Jakub Jelinek , "MacLeod, Andrew" , GCC patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 11:41 AM Aldy Hernandez wrote: > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener > wrote: > > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez wrote: > > > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek wrote: > > > > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote: > > > > > 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]. > > > > > > > > I think [3.0, 5.0] printed that way currently means U maybe NAN, > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN. > > > > > > Right. I don't print any of the "maybe" properties, just if they're > > > definitely set or definitely clear. I'm open to suggestions as to how > > > to display them. Perhaps NAN, !NAN, ?NAN. > > > > There's no NAN tristate. Your "definitely NAN" would be simply > > ][ NAN, that is, the value range only contains NAN. Your !NAN > > is and non NAN. Likewise for the sign, the > > range either includes -NAN and NAN or one or none of those. > > For signed zeros you either have [-0, upper-bound] or [0, upper-bound] > > where it either includes both -0 and 0 or just one of them > > But there is a tristate. We may definitely have a NAN, definitely not > have a NAN, or the state of the NAN is unknown. Sure. But we are talking about sets of values a variable can have (a value "range" where "range" is a bit misleading for something like a NAN). The set of possible values either includes NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN). A set cannot include or not include a "maybe NAN". > Say [3,5] ?NAN. > That's [3,5] with the possibility of a NAN. On the true side of x >= > 5.0, we'd have [5.0, INF] !NAN. On the false side we'd have [-INF, > 5.0] ?NAN. On the true side of x >= 5.0 the set of values is described by the [5., +INF] range. On the false side the set is described by the union of the range [-INF, 5.0] and the { -NAN, +NAN } set. There's no may-NAN. There's also no ?4.0, the range either includes 4.0 or it doesn't. Note the frange class should probably have APIs that match the FP classification functions isfinite(), isnormal(), isnan(), isinf () and signbit() likewise compares like isunordered() . Note isnormal () exposes that FP numbers can be denormal, not sure if that's worth tracking. > With this representation we can fold __builtin_isnan() even on an > unknown value... say on the true side of x == y we know that both x > and y cannot be NANs...but on the false side we know nothing so there > is the possibility of a NAN. > > I do like your idea for signed zeros. I think I could make it work > and get rid of the sign bit. > > Aldy > > > > > > I'm mostly worried about removing a NAN from the IL that was going to > > > signal, or some such. While I agree with you Richard, I just want to > > > make real sure, because getting something wrong in the frange or > > > range-ops bowels means the problem becomes pervasive to all of ranger > > > ...and threader...and loop ch...and vrp, etc etc. I just want to take > > > more time to test things. I promise it won't stay varying too long. > > > > There's sNANs and qNANs, but I think for value-ranges we should > > concern ourselves only with qNANs for now and leave sNANs VARYING. > > All operations only ever produce qNANs (loads can produce sNANs). > > > > Richard. > > > > > Aldy > > > > > >