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 E5DF93858288 for ; Tue, 16 Aug 2022 10:26:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E5DF93858288 Received: from mail-oa1-f69.google.com (mail-oa1-f69.google.com [209.85.160.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-329-CtgDsEYvNp6W3e2YWzXJ8A-1; Tue, 16 Aug 2022 06:26:01 -0400 X-MC-Unique: CtgDsEYvNp6W3e2YWzXJ8A-1 Received: by mail-oa1-f69.google.com with SMTP id 586e51a60fabf-10e7667b972so2412802fac.12 for ; Tue, 16 Aug 2022 03:26:01 -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; bh=CRCeffS4kc9Zgox5FwUO1w50JooaWtbdnLhau/6Rts8=; b=R6/AbMyZL9w/AAWMaJoFDTszPIJiY64jVcugb3PL+cOnuMGIbcZkWJ5YFjEK8Fei6x N5Qrpew+rNiSRJ0jjoKXbDBtiuPMuyU52glFKJi2iDh38RzXmnW6RtE6BXovckvEDF2n 9zCl2RwOGLTF/7BUExIa+hFLXHDr6b2E0rkDyqqKgN9uRZsuck3BwertVMhesNkLbaqt f+So9HdLP4gXs/XoBi+2CplWcbQJ+WvLh+6G4oybS9I5Ust4dMEr69lcrsievRyvDNBr PQlJSDWVQtAZ/PYklqZeCYSH1JBatdlBZl1oZI+G7Rg5YKGC8bBhO8Go7PpwZV5oRgl0 OErw== X-Gm-Message-State: ACgBeo1PX/eu/x+1024eTjfIq5dxkr/a3rSMO1AK5tfG/IBKEACUfuHI ZnFdeXJRwwkPvXyymhhOR7c1Ls4oDdC00EQkTrA8W7nO5w0mZQsrNk1tnJ8VnLvlRdrBlCGbC6C d5uBLX90mZ/7tBbjnHU1PVzFSVTkWtft9sg== X-Received: by 2002:a05:6870:b617:b0:10d:f7ce:50df with SMTP id cm23-20020a056870b61700b0010df7ce50dfmr12763059oab.36.1660645560759; Tue, 16 Aug 2022 03:26:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR63GL20GsmI70NlnqBGqzkXQLW2p/WAIn8x4w1jrfkIBdm8cmZzZjgY5CEeRcjp8gNzu4TUuZtWOIB3jL4Tm50= X-Received: by 2002:a05:6870:b617:b0:10d:f7ce:50df with SMTP id cm23-20020a056870b61700b0010df7ce50dfmr12763054oab.36.1660645560554; Tue, 16 Aug 2022 03:26:00 -0700 (PDT) MIME-Version: 1.0 References: <73820.122081107421800679@us-mta-533.us.mimecast.lan> In-Reply-To: From: Aldy Hernandez Date: Tue, 16 Aug 2022 12:25:49 +0200 Message-ID: Subject: Re: [PATCH] Tame path_range_query::compute_imports To: Richard Biener Cc: Andrew MacLeod , 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.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, 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: Tue, 16 Aug 2022 10:26:05 -0000 On Mon, Aug 15, 2022 at 11:53 AM Richard Biener wrote: > > The remaining issue I have with the path_range_query is that > we re-use the same instance in the back threader but the > class doesn't provide any way to "restart", aka give m_path > a lifetime. The "start a new path" API seems to essentially > be compute_ranges (), but there's no convenient way to end. > It might be more appropriate to re-instantiate the path_range_query, > though that comes at a cost. Or abstract an actual query, like > adding a Yes, compute_ranges() is the way to start a new path. It resets exit dependencies, the path, relations, etc. I think it would be clearer to name it set_path (or reset_path if we want to share nomenclature with the path_oracle). Instantiating a new path_range_query per path is fine, as long as you allocate the ranger it uses yourself, instead of letting path_range_query allocate it. Instantiating a new ranger does have a cost, and it's best to let path_range_query re-use a ranger from path to path. This is why path_range_query is (class) global in the backwards threader. Andrew mentioned last year making the ranger start-up 0-cost, but it still leaves the internal caching the ranger will do from path to path (well, the stuff outside the current path, cause the stuff inside the path is irrelevant since it'll get recalculated). However, why can't you use compute_ranges (or whatever we rename it to ;-))?? Aldy > > query start (const vec &); > > and make range_of_* and friends members of a new 'query' class > instantiated by path_range_query. I ran into this when trying > to axe the linear array walks for the .contains() query on the > path where I need a convenient way to "clenanup" after a path > query is done. > > Richard. >