https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697
--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- Sharing a cache with say the ranger is a no go, because the path_range_query's cache is specific to the path, but perhaps we could share the path's cache between constructions providing a constructor that takes the cache as you suggest. The path query has a bitmap to determine if a cache entry is used (m_has_cache_entry), so I think we could reuse a dirty cache since the bitmap gets cleared at construction. I assume the main culprit is the path_range_query's being instantiated from class back_threader? If so, there could be one cache per back_threader? Hmmm, perhaps we'd have to call ssa_global_cache::clear_global_range() before each set_global_range() for reused caches otherwise the latter would try to reuse slots (fits_p and all that). Also, is it the clearing part of safe_grow_cleared() that is taking up the time, or just safe_grow. Cause ISTM we don't need to clear the cache for use in path_range_query. So we could even add a flag to use safe_grow() instead of safe_grow_cleared() for the path query?
