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.133.124]) by sourceware.org (Postfix) with ESMTPS id B98B63858CDA for ; Mon, 5 Sep 2022 11:45:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B98B63858CDA 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=1662378339; 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=pwWyuTZb3hNgjEvEom2wsQqevexeNLSTM9PpIOjGly8=; b=cXjRbwms9YZVbXqdwnH2VaxmVQ07at9BBejtE3hw6OnLgavUHWr0/zHPiIeqanDQRiPO6W qSz34Bj5iyDkMe0gAzd2XMiYTVn4Or328mRNJRe7CjknpLMIE5M3nT0IwgonWVLvC3HChq AEo9PSkOsqaC/TXgB4mQsyg6adrCdjo= Received: from mail-oo1-f72.google.com (mail-oo1-f72.google.com [209.85.161.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-54-ZLqA-F7SMt-YsTFjpZvBRA-1; Mon, 05 Sep 2022 07:45:38 -0400 X-MC-Unique: ZLqA-F7SMt-YsTFjpZvBRA-1 Received: by mail-oo1-f72.google.com with SMTP id m16-20020a4a2410000000b0044a8eef0d7dso668866oof.12 for ; Mon, 05 Sep 2022 04:45:38 -0700 (PDT) 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=pwWyuTZb3hNgjEvEom2wsQqevexeNLSTM9PpIOjGly8=; b=7jPbUhprSHb5/pSyPLobpoOukelLkoLxk65opbhU7a6/cUS1BjuoexGBdxaRkxiHv5 DqliCXkzJofjqNGsGOx3CuswRwD7GfOkeBFnSIpl0XU9/qOlt6xQFPWvQ0k1dzfdWmkR UWp8el7/TSdemcnhiweNN6wB9JmKDXw9p6snddKiZL8gtap7uO8Hv1FLd7KGOfG/FkvQ TP3yxPDKm4R/XrKJRCqZVl7gKL05P705ndw9vklyva02oVa4ernnMi27/6d95BZVTfEd UO8N2w+8K95TLQr9iGSgUJ/P5xvN6K7rvJ26B+yr11pSOydl+rpohV1QvQfMMIPhri95 xekQ== X-Gm-Message-State: ACgBeo3zspCfLwNEnufku1J1YrIezJGxyDVXoICnCMM/crD6A0Ghj7Cx VrMsRCb44PJL6bFRc5zKfys0D1uR5qJ2xfLh/eMngIiSGH78qnpubHP5/DOiywY/Ixae9SPApaH Ad8tMNBABFh2TN+mkczeZTMNJsrtxUZ7UJg== X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr9103893oae.265.1662378337471; Mon, 05 Sep 2022 04:45:37 -0700 (PDT) X-Google-Smtp-Source: AA6agR7F/HCF5WirgwSc0TjcTGDFJ+y8D64PfU22YzVTDY+NhGaMtlGC0X7j48F0jSnzTeTZGc6iTw7kTCXYqJ95KeE= X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr9103882oae.265.1662378337166; Mon, 05 Sep 2022 04:45:37 -0700 (PDT) MIME-Version: 1.0 References: <20220905062301.3240191-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 5 Sep 2022 13:45:26 +0200 Message-ID: Subject: Re: [COMMITTED] Be even more conservative in intersection of NANs. To: Richard Biener Cc: Jakub Jelinek , "MacLeod, Andrew" , GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 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? This is just a representation detail, and I have no problem with it, except that it'll take time to implement. Patches welcome though ;-). 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 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? 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. Aldy Aldy