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 0E6563858D1E for ; Thu, 1 Sep 2022 18:25:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0E6563858D1E Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-386-D2NF_1UdOpC3kUj66KqzXQ-1; Thu, 01 Sep 2022 14:25:41 -0400 X-MC-Unique: D2NF_1UdOpC3kUj66KqzXQ-1 Received: by mail-ot1-f72.google.com with SMTP id r28-20020a056830237c00b006392b014be9so9322332oth.0 for ; Thu, 01 Sep 2022 11:25:41 -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=Qm2VSb4jT3pT3jSecbPgmmUcc6XaEatVc4lWOp1JUL4=; b=SsBV3J631FHgp5jRmpb5j+mr7T2YI9EjjkGahA2+thNMuT27sUxfxtSGBfuO3dZkJe lYnSQP8hyShg2w5wPaRu2lSL3qDdp1K1ylw9QP14SAqFBCQj8Hp0qCbIUiQH8uVcNi9V JLBGTrA4lDchtMUmEVyq6bDkqOhsMyORouG8IbQRWDAEITZTffKI8UPuFaLbDEsvNpaM lBMcRCLNbgrvLI0WcwpgrxDIvW/sfzCw9RaxRm6Lp8pmFZuTP7Gh7F1jfgveWFXLpFgr kGL5OEpFFGU7HXDiTnGuEtJwmWL05buXMF7kTbSnwCQxwCGXi/IlXeXNIWEW/t4V3OFx L2YQ== X-Gm-Message-State: ACgBeo0+/TmrLNzq1xXJABMkwn7DMnwUqCt1JMWZ4nmAVqweTt4xf2jE rSnzkxi4FFjPkU+9G2G7NyAS3Z0w8gDcTKkmKO3uK05QuFod+cDuGO3eXDWPDjavd/LZehej8H+ xZKkHZP5d1rE/g2jUBqjT0Qojf400isvuPA== X-Received: by 2002:a05:6808:f0f:b0:343:2e0e:ac52 with SMTP id m15-20020a0568080f0f00b003432e0eac52mr237735oiw.36.1662056740770; Thu, 01 Sep 2022 11:25:40 -0700 (PDT) X-Google-Smtp-Source: AA6agR6llpnIl0nSyZ9ddOmgToLTlyHmi5JEPVliaSxtzDx+0R4Iav4qi/NWAnsu9VKZEG9qtuoe3raiLTyq9YZyB5U= X-Received: by 2002:a05:6808:f0f:b0:343:2e0e:ac52 with SMTP id m15-20020a0568080f0f00b003432e0eac52mr237724oiw.36.1662056740558; Thu, 01 Sep 2022 11:25:40 -0700 (PDT) MIME-Version: 1.0 References: <20220901111851.2595874-1-aldyh@redhat.com> <20220901111851.2595874-2-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Thu, 1 Sep 2022 20:25:29 +0200 Message-ID: Subject: Re: [COMMITTED] Implement ranger folder for __builtin_signbit. To: Joseph Myers Cc: GCC patches , Jakub Jelinek , "MacLeod, Andrew" X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.4 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 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: Thu, 01 Sep 2022 18:25:46 -0000 On Thu, Sep 1, 2022 at 6:41 PM Joseph Myers wrote: > > On Thu, 1 Sep 2022, Aldy Hernandez via Gcc-patches wrote: > > > Now that we keep track of the signbit, we can use it to fold __builtin_signbit. > > > > I am assuming I don't have try too hard to get the actual signbit > > number and 1 will do. Especially, since we're inconsistent in trunk whether > > we fold the builtin or whether we calculate it at runtime. > > The main thing to watch out for is cases where, in the abstract machine, > there is a single call executed to __builtin_signbit, but after code > transformations, some uses of the result of that call are optimized to use > a 0 or 1 value and other uses end up using a runtime value - inconsistency > between different calls is fine, inconsistency where only a single call is > executed in the abstract machine isn't. (Cf. bugs 102930, 85957, 93681, > 93806, 93682, for example; the test in bug 93806 comment 27 is the sort of > thing to try.) Can't we just be consistent with the runtime? I'm happy to return whatever value is appropriate for the architecture. It doesn't have to be 1. Though ISTM that if we know the sign on one side of a conditional, we should know the sign on the other side of the conditional, so we should fold all uses of __builtin_signbit in that case. So maybe we're ok. On the other hand, we could narrow the range to nonzero, which we can model perfectly for integers (and __builtin_signbit returns one). If we take this approach it means we can't fold: if (x < -5.0) num = __builtin_signbit (x); but we could fold: if (x > 5.0) num = __builtin_signbit (x); since that's always 0. And it also means we could fold conditional checks against zero/nonzero: void func(float x) { if (x < -5.0 && !__builtin_signbit (x)) link_error (); } Whatever works for y'all. Aldy p.s. My head exploded after reading half of PR93806. I should just go back to integers.