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 C69CB3858D3C for ; Fri, 18 Mar 2022 13:07:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C69CB3858D3C Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-111-LrBU4M8YNAuHZYkrIInbvg-1; Fri, 18 Mar 2022 09:07:50 -0400 X-MC-Unique: LrBU4M8YNAuHZYkrIInbvg-1 Received: by mail-qk1-f199.google.com with SMTP id q24-20020a05620a0c9800b0060d5d0b7a90so5305503qki.11 for ; Fri, 18 Mar 2022 06:07:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0bS8k7aBd994Bm/4Gj1PRO3++JLmrVkASM3Oa+zgA50=; b=1vGs/ypnamFZEdNzOd4OfxdsI41PN0ica7CU4T7k0NThJuEx3WLT3XCLGps9S0hkOC ssunEc6g3Cotm1cIUY2A1xQzdkGPvofaa4zGP55tFXXdQAW7nYjiFZXlJl6eRqFPwWOz 91PWm7SdJemNfc4i3JkNvQMSk1xWRtd15xfjzWdsWUY1ENu77bn3oa4o7YtzqypvgSRY dV3MSLhQI5YEw5qUcIQh5CmKHz48MIOSqEoEHV9cRRyGl9qLtC1sQm24ZuUjYJod0g5y rS9yRNlxD4z952gST5L6MqvK4N0ArZ7rrZXX29sr4uROGgCC6jdVrvfADNTzLwlk4aM4 k33A== X-Gm-Message-State: AOAM530wvcZ3+HT6ctNBSY+FSJscR2q8yGChxFRVxDPVSJb3JfIAayOg M6Y9Fpp0spFFWMZIoaOToRA777P7AN0FYs3eypQg/uyK6YOhwqcBuDzX1kN1eveP/b7vyrdkuJq 1XuWSplQCeCo9e2SSQg== X-Received: by 2002:a05:622a:1ba5:b0:2e1:a8b5:d772 with SMTP id bp37-20020a05622a1ba500b002e1a8b5d772mr7312136qtb.409.1647608869751; Fri, 18 Mar 2022 06:07:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyQSn/RqLWpXN+095gWp27Mho3isILB7oFxN6nKvBycJ/sf7EEbssjnkbjBeqT2qm76R5u/Kw== X-Received: by 2002:a05:622a:1ba5:b0:2e1:a8b5:d772 with SMTP id bp37-20020a05622a1ba500b002e1a8b5d772mr7312116qtb.409.1647608869438; Fri, 18 Mar 2022 06:07:49 -0700 (PDT) Received: from ?IPV6:2607:fea8:a262:5f00::9b6f? ([2607:fea8:a262:5f00::9b6f]) by smtp.gmail.com with ESMTPSA id q8-20020a05622a030800b002e1c9304db8sm5598324qtw.38.2022.03.18.06.07.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Mar 2022 06:07:45 -0700 (PDT) Message-ID: Date: Fri, 18 Mar 2022 09:07:42 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Ignore (possible) signed zeros in operands of FP comparisons. To: Roger Sayle , 'Jeff Law' Cc: 'GCC Patches' , 'Richard Biener' , Aldy Hernandez References: <001c01d837d9$4c8bf060$e5a3d120$@nextmovesoftware.com> <009701d83843$26293a30$727bae90$@nextmovesoftware.com> <00dc01d83a9b$e50e2140$af2a63c0$@nextmovesoftware.com> From: Andrew MacLeod In-Reply-To: <00dc01d83a9b$e50e2140$af2a63c0$@nextmovesoftware.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2022 13:07:53 -0000 On 3/18/22 03:43, Roger Sayle wrote: > Hi Jeff/Andrew, >> If you're going to do more work in this space, you might want to reach out to >> Aldy and Andrew to see if there's space for collaboration. > One (clever?) suggestion that I do have for ranger would be to add support for > an additional value_range_kind, VR_NONZEROBITS, which would be a variant of > VR_RANGE (for unsigned types?) and require very few changes to the existing I think were ahead of you here.. Tracking known zero and one bits within irange as an adjunct has been in plan for awhile, just priorities haven't allowed us to get to it until recently... Theres a bunch of stuff already in the hopper for the next stage1 that Aldy has been working with... he can expound upon it, but we plan to use both masks and ranges together  as appropriate. > code. Just like VR_RANGE all values would lie in [MIN, MAX], so by default > treating this value_range_kind identically to VR_RANGE there should be no > visible changes, but the change in semantics is that MIN has the minimum bits > set, and MAX, the maximum bits set [equivalent to the RVAL and RMASK pairs > from CCP's bit_value_{bin,un}op]. Hence, the VR_NONZEROBITS range [2,7] > would represent the possible values {2, 3, 6, 7} rather than {2, 3, 4, 5, 6, 7}. > For a small number of bits, int_range can already handle this with multiple > irange spans, but adding this representation would allow the unification of the > bit-based propagation performed in tree-ssa-ccp with the range-value based > propagation performed in EVRP/ranger, allowing the clever forwards/backwards > functionality. > > As Andrew's recent (partial) review points out, tracking the effect of operations > like BIT_XOR_EXPR on VR_RANGE is much more complicated than on the > proposed VR_NONZEROBITS. > > Alas, I'm not the sort of contributor to make large infrastructure changes > myself, but if the above functionality were in place, I/the compiler would > be able to make use of it. > And this is exactly what we are hoping.. we provide the structure and someone who is better at the underlying detail interaction can flesh out whatever specifics they find interesting. Andrew