Re: [PATCH] Tame path_range_query::compute_imports

[Aldy Hernandez <aldyh@redhat.com>]

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).

However, why can't you use compute_ranges (or whatever we rename it to ;-))??

Aldy

>
>   query start (const vec<basic_block> &);
>
> 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.
>