From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by sourceware.org (Postfix) with ESMTPS id DD36B3858CDA for ; Mon, 5 Sep 2022 12:16:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DD36B3858CDA 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-ed1-x531.google.com with SMTP id z21so1081156edi.1 for ; Mon, 05 Sep 2022 05:16:45 -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=ba+YkwmfKuKe9k0iDNUnKQGLpOZ6vBLZtRuf4suEO5k=; b=MtGz/VAKLOcOx353EQMp62Y0DLn3A4UIEjmB+n4DPWTX4PBCEA8L91bS0m117Y7U8p d1v10f59QGK39KOIRn3myczeICT0+pRxlABQxf72snMi4nkYZ2rKdmwjIf3Lx7cMtkGo chD07PPI3zqqoQYyLHThfMQkPQHXdj9wyBkdpkJQC/KymhrKp3b3S9LHg0mw5v07dZoW xPNv0tgmpk6NvprUZKNJSIb+RDcc2R3a6jbQrzmZ5GeBX3Uh8B+JZgF9IUoGmMBs95cZ g0OSHcCBln0SMxGqCwJfzW7SrLcksh3UVQzWA6fMP7sMs2ecUq2v5BhANvLwuVrP6Ph/ 96XQ== 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=ba+YkwmfKuKe9k0iDNUnKQGLpOZ6vBLZtRuf4suEO5k=; b=ngvCE+F0057XtUiw1VJmGMMdfH3n0c1MSvE/fiUWGr/0J+/PI3mTdZxlcZubzpA9+p adT0qZPRFlw3SavU/zgQbLZR23lAulC9G04WbxtcOP4HdgWx+sqUn0Cuc71jBkxzkzBm 65MkQN/50jVTU/5/vfJsy8EosZ7VRTbzApoGTX8chaKva56thEpBwOrM+Y5xuQhZJEaE KVgP87BW/hSasy1g2y0bstqOd6VKogP815EHDIoASCtjbt/LV63BImzq9OLCW/gwiyUR G4qdqFqd2uNZArnqEfX9fKP5clzJNggUO+bftNXdVDyfGoUKLHGICOvPsnjpeBeKxbjH 7D0w== X-Gm-Message-State: ACgBeo0nZZ3KJU0jI6YXtcYlfJKWe4oKZpH96pdvgJ8ATCdrhXI3P9qp Us1R9Z/R8WmSRspY+TMdpPZJjtZ4v7wSmv/+TYk= X-Google-Smtp-Source: AA6agR5vNs/bNXr8/moqRhQ+G/3bONrYJGF1ugnSzgpwQoHOvZXGCqLoTV3CSXaB8REtalTp8vG+9lRHtRp4LMioGeQ= X-Received: by 2002:a05:6402:2b98:b0:43e:107:183d with SMTP id fj24-20020a0564022b9800b0043e0107183dmr43101714edb.366.1662380204497; Mon, 05 Sep 2022 05:16:44 -0700 (PDT) MIME-Version: 1.0 References: <20220905062301.3240191-1-aldyh@redhat.com> In-Reply-To: From: Richard Biener Date: Mon, 5 Sep 2022 14:16:32 +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=-2.1 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 1:45 PM Aldy Hernandez wrote: > > On Mon, Sep 5, 2022 at 12:38 PM Richard Biener > wrote: > > > > On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez wrote: > > > > > > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener > > > wrote: > > > > > > > > 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. > > > > > > Ah, ok. I see where the confusion lies. You're missing that we don't > > > have sub-ranges like we do for irange. We only have two endpoints and > > > a set of flags. So we can't represent [3,4] U NAN "elegantly". > > > However, we can do it with [3,4] ?NAN. This is by design, but not > > > permanent. I don't have infinite time to work on frange on this cycle > > > (I have other things like wide-ints conversion, prange, removal of > > > legacy, etc etc), so I wanted something that worked with endpoints, > > > signs, and NANs, that's about it. If at a later time we decide to go > > > full throttle with the ability to represent sub-ranges, we can do so. > > > Heck, you're welcome to try-- just let me finish the initial > > > implementation and get it working correctly first. > > > > > > It is more important right now to get the usage than the > > > representation right. We could always add sub-ranges, or change the > > > representation altogether. What is very important we agree on is the > > > usage, so your suggestions about the FP classification functions below > > > are golden. I'll look into that. > > > > > > Does that make sense? > > > > Not really. I didn't ask for sub-ranges for NAN, but even with a "flag" > > it should still semantically be [3, 4] U NAN or [3, 4]. It's not necessary > > but confusing to leave the notion of a SET here. > > > > > BTW, [NAN, NAN] is a special case. It doesn't behave like a > > > singleton. Both endpoints must match. We assert this much. We don't > > > propagate it. We can't do equality to it. The fact that it lives in > > > the endpoints is just an implementation detail. > > > > And even here, having [NAN, NAN] but [3, 4] with maybe-NAN flag > > is just inconsistent. Why's that necessary? Is there no "empty range" > > (aka UNDEFINED) for frange? > > So what you're suggesting is replacing the tri-state NAN and SIGN bits > with two separate NAN flags (+NAN and -NAN) and representing actual > NANs in the undefined range? Yeah. Note if you keep the SIGN bits the two-bit NAN state would still drop to just one bit - NAN or not NAN. I'm mostly opposed to the idea that we need a "maybe" in addition to NAN and not NAN. > This is just a representation detail, > and I have no problem with it, except that it'll take time to > implement. Patches welcome though ;-). It's also an API and debug (dumping) detail if that implementation detail is exposed. I'm mostly concerned about that and what documentation suggests. > May I suggest we agree on how to access this information (API), and > then we can change the implementation details later? > > For instance, what you suggest for isfinite, isinf, isnan, etc. What > does isfinite return for [0,INF]? Will isfinite return whether the isfinite does (see manual page): isfinite(x) returns a nonzero value if (fpclassify(x) != FP_NAN && fpclassify(x) != FP_INFINITE) so it returns false. (it's not isinfinite). isinf returns false as well here. There's a reason I didn't suggest to implement fpclassify because there's no "I don't know" result. > range *includes* INF? So true? Similarly for [3,4] NAN (in your > preference). Shall we return true of isnan?, or only for an actual > NAN? Only for an actual NAN. But yes, implementing these may result in confusing if people use !isnan() because that wouldn't mean the number is never a NAN. So maybe instead have, similar to the poly-int stuff, maybe_inf (); known_inf (); maybe_nan (); known_nan (); known_finite (); // maybe_finite () doesn't make much sense to me > And yes, we do have an UNDEFINED, but we take UNDEFINED to mean the > empty set across the board. We like checks for undefined to be > fast...i.e. just checking the m_kind field, not having to worry about > checking if some other flag is set. Also, there are still some silly > passes making use of vrange::kind() which is deprecated, and if NAN > was represented with the VR_UNDEFINED enum set to m_kind, it'll cause > problems. But I'm sure you can come up with another way of > representing NAN. I really don't have strong opinions about > representation details. Hmm, we have undefined_p () which frange could overload. Btw, if you don't have subranges then how would you represent {-Inf, +Inf}? Not that this is likely to occur in practice. > > Aldy > > Aldy >