From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 9245A3858424 for ; Tue, 31 Aug 2021 06:00:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9245A3858424 Received: by mail-ej1-x62b.google.com with SMTP id a25so36065521ejv.6 for ; Mon, 30 Aug 2021 23:00:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TadWNmYg82rBhXhSsj9S+bHGVC5K5zecwhjHYt7giF4=; b=ipCtpEY1jwMTQY4SapYtMGUP5nz3EKrsNAu9a2KfrnFwB13OrMrvujknXV7QTbTciP 29jwX59xm9VsEOvq6vMlj1+cTm+yjVSI8NdOBeqeFsw8NrP1xXdIleEq9tX6AHrgzzPx ZScE9CPrrbfGMxbquruhLf24HcGn34O3E5gTuHvI2itnDOIHp7yewF2ezQHNSysZELLJ 34Kv1iWS1Wc1pgB+NN+PjIKGYD/zk5rhxNOaNgcy4zQWfzwz4xR3YHrM5C5jun2HdC74 C9RS2OdE7TS4KqIfxiOKhl/cnZiNvn6lLIHAgHW012E72Lilp2rRFoVwQo7ik0cTTNB/ FYhQ== X-Gm-Message-State: AOAM531aGNDpbyDC6Di2eR/rRRMrc2xfDTqIDxWaVUbUvqWYc0WYTu5s ZwAPa/f0LaOTPAR74nU6XYa7RXaL2SV7EGEmFBY= X-Google-Smtp-Source: ABdhPJyCMaR/FauCe2YuWDo04F99KHP2dEsTwTFQVmwUjvxEnXzKr9z11fOJiK06d/EdGzNlN+X3xy9y9+9N5H2wBMk= X-Received: by 2002:a17:906:4c89:: with SMTP id q9mr29215281eju.118.1630389642310; Mon, 30 Aug 2021 23:00:42 -0700 (PDT) MIME-Version: 1.0 References: <9a041eca-97c3-f250-8bab-8fadc72cd283@gmail.com> <0109253d-45e9-5c59-210d-2edcf983e4b3@redhat.com> <71d7a933-6942-1598-0cdd-5413f03fc188@gmail.com> <6dc30efb-d4d1-1633-5b59-4840b79c2b48@redhat.com> <6cd5035f-77f7-a8ce-1c60-7c41c8c38214@gmail.com> In-Reply-To: From: Richard Biener Date: Tue, 31 Aug 2021 08:00:31 +0200 Message-ID: Subject: Re: [PING #2][PATCH] enable ranger and caching in pass_waccess To: Martin Sebor Cc: Andrew MacLeod , gcc-patches , Aldy Hernandez Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: Tue, 31 Aug 2021 06:00:54 -0000 On Mon, Aug 30, 2021 at 4:27 PM Martin Sebor wrote: > > Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578135.html > > Are there any further comments on the patch? > > Richard, you were kind enough to review the first two patches in this > series. Would you mind doing the same for this one? It continues in > the same vein. OK. Richard. > Martin > > On 8/25/21 3:26 PM, Martin Sebor wrote: > > On 8/25/21 10:14 AM, Andrew MacLeod wrote: > >> On 8/25/21 11:20 AM, Martin Sebor wrote: > >>> Ping: Andrew, did I answer your questions? Do you (or anyone else) > >>> have any other comments on the latest patch below? > >>> > >>> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577865.html > >> > >> > >> I wasn't attempting to block it, its outside my review purview.. > >> > >> I was merely commenting that you should not need a pointer to a > >> range_query at all anymore > >> > >> > >>> > >>>> > >>>>> > >>>>> Are you planning to transition to using the get_range_query() > >>>>> interface instead of keeping a range_query pointer in the > >>>>> pointer_query class? > >>>> > >>>> This pass and to a smaller extent the pointer_query class that's > >>>> used by it and the strlen pass are still a work in progress. > >>>> I also still need to convert the strlen pass to use Ranger and > >>>> I expect it will take some changes to pointer_query. So at that > >>>> point, if going through get_range_query (cfun) everywhere is what > >>>> you recommend, I'm happy to do it. > >>>> > >> absolutely. you should not need to even know whether you have a ranger > >> instance running or not. get_range_query will give you whichever is > >> active, and there is ALWAYS something active.. defaulting to the > >> global version. > >> > >> the code in get_range() seems to be the end of the call chain which > >> uses the pointer and should be consolidated to something much simpler > >> > >> if (rvals && stmt) > >> { > >> if (!rvals->range_of_expr (vr, val, stmt)) > >> return NULL_TREE; > >> > >> <...> > >> > >> // ?? This entire function should use get_range_query or > >> get_global_range_query (), > >> // instead of doing something different for RVALS and global > >> ranges. > >> > >> if (!get_global_range_query ()->range_of_expr (vr, val) || > >> vr.undefined_p ()) > >> return NULL_TREE; > >> > >> > >> This entire section can boil down to something like > >> > >> if (!get_range_query (cfun)->range_of_expr (vr, val, stmt)) > >> return NULL; > > > > So get_range_query (cfun) will never be null? And no special handling > > of INTEGER_CST is needed, or checking for SSA_NAME. Nice. Attached > > is another revision of the same patch with this function simplified. > > > > (FYI: I expect the whole function to eventually go away, and to make > > other similar simplifications, but I'm not there yet.) > > > >>>> PS There has been an effort to get rid of global variables from GCC, > >>>> or, as the first step, to avoid accessing them directly(*). If and > >>>> when that happens, it seems like each pass will have to store either > >>>> the ranger instance as a member (directly or indirectly, via a member > >>>> of a class that stores it) or the function passed to pass::execute() > >>>> if it wants to access either. > >>>> > >>>> [*] https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573975.html > >>>> The patch at the link above wasn't approved but IIUC removing globals > >>>> from GCC is still a goal. > >>> > >> I have no idea what direction that is going, but the net effect will > >> be the same in the end. You'll be calling get_range_query() with > >> either the function pointer, or the pass pointer, or something.. but > >> you should never need to pass around a pointer to either a ranger or > >> range-query. As I said earlier, this will likely be a pass property > >> and accessed thru the pass eventually... but until then, use what we > >> have.. cfun. It'll be trivial to transition down the road to whatever > >> the ultimate solution is. > > > > Okay, I'll do that in my future changes. > > > > Martin >