Re: [PATCH] Tame path_range_query::compute_imports

[Aldy Hernandez <aldyh@redhat.com>]

On Tue, Aug 16, 2022 at 3:48 PM Andrew MacLeod <amacleod@redhat.com> wrote:
>
>
> On 8/16/22 06:25, Aldy Hernandez wrote:
> > On Mon, Aug 15, 2022 at 11:53 AM Richard Biener <rguenther@suse.de> 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

I forgot about the def chains.  That should be fine however, since we
use the gori from within the ranger that got passed down.

Aldy