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 8B4403857BA4 for ; Tue, 16 Aug 2022 13:48:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B4403857BA4 Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-177-H6fb618NOfejlCgjkxA96w-1; Tue, 16 Aug 2022 09:48:02 -0400 X-MC-Unique: H6fb618NOfejlCgjkxA96w-1 Received: by mail-io1-f70.google.com with SMTP id c9-20020a05660221c900b00688a5a621afso1518213ioc.9 for ; Tue, 16 Aug 2022 06:48:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=Hshy2C57If7PeT98xO1rfM2jpMssmWr/pqgCsaKe74s=; b=gtBRIIpsDQmQZaW1nGGaibP4NFopjUJEK2ZCO5Iq5K/8YXSSJs7bGZRM8OEmK70rFu NFMvpV5Zk1xGtEGqX5GIl3X7YcYu7OGmu6yWfiw3IcDJ/b5xjBEAT3+6FlZVmCkHkH8N tFTcNZEOCCljtMw+Jcatmv7nwkF7g2yq6i7GF5dHfQRQLqPeb8SrBUPbkN+kCfWYLDK6 mB/docbrcWR66F+EN9xzlZ5ETkGjuPnklCakdrTYAOXVn0aQ2aRcD8SYAemE7Us2d4bi sbNvb7PKB/T1/vI03lHW+A4bOyBa2Q77DeFGZySE2xIOwd510nW/vvY+nFGuoaY41eID xo0w== X-Gm-Message-State: ACgBeo1/MYPLAQ7zUzo0ecT483b2k9mCrIkzgBqzTkMIpGzmy+TwAqoz mPhlObhAoTfX9Wq0JNjKvGXfCf8h7dm3ArYfs5dIociD32goBKW6sF0LA04855LE25ugS2L5AmO hZ+1lwj5cXg15PA/tCA== X-Received: by 2002:a05:6638:480a:b0:346:a98b:1764 with SMTP id cp10-20020a056638480a00b00346a98b1764mr1584689jab.108.1660657681876; Tue, 16 Aug 2022 06:48:01 -0700 (PDT) X-Google-Smtp-Source: AA6agR6fpWDvZCDHIT1kPHNNUqQJGSOeZsL6mBMpbAIo52sy7ACEevw3RDpI9X8aQCoqAKPu7dzhHg== X-Received: by 2002:a05:6638:480a:b0:346:a98b:1764 with SMTP id cp10-20020a056638480a00b00346a98b1764mr1584682jab.108.1660657681586; Tue, 16 Aug 2022 06:48:01 -0700 (PDT) Received: from ?IPV6:2607:fea8:a263:f600::8850? ([2607:fea8:a263:f600::8850]) by smtp.gmail.com with ESMTPSA id a4-20020a92c704000000b002e6c7382d85sm607708ilp.71.2022.08.16.06.48.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Aug 2022 06:48:00 -0700 (PDT) Message-ID: <9b5f86c8-6920-843d-a766-7fe9166c44da@redhat.com> Date: Tue, 16 Aug 2022 09:47:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Tame path_range_query::compute_imports To: Aldy Hernandez , Richard Biener Cc: gcc-patches References: <73820.122081107421800679@us-mta-533.us.mimecast.lan> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 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_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 13:48:07 -0000 On 8/16/22 06:25, Aldy Hernandez wrote: > 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). Yes, you will want to have one instance of ranger regardless... just pass it to whatever/however many other instances you want to build paths from. Ranger itself is primarily to provide range-on-entry to the path.  Trying to use it for values within the path would bring in values outside the path as it doesnt understand you have selected on certain edges along the way. The GORI engine within ranger can be utilized within the path because GORI never looks outside the basic block being asked about, other than thru the range-query that is provided to it. SO its perfectly safe to use within the path. As both GORI and ranger cache things and share the def chains, its far more efficient to have a global instance that is just utilized.   Even a zero-cost start up would incur costs as it recalculates the same things over and over Andrew