[Bug tree-optimization/108697] New: constructing a path-range-query is expensive

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108697

            Bug ID: 108697
           Summary: constructing a path-range-query is expensive
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Looking at the profile of the compiler.i testcase from PR26854 one can see
ssa_global_cache::set_global_range very high in the profile, specifically
the clearing of m_tab:

bool
ssa_global_cache::set_global_range (tree name, const vrange &r)
{
  unsigned v = SSA_NAME_VERSION (name);
  if (v >= m_tab.length ())
    m_tab.safe_grow_cleared (num_ssa_names + 1);

note this cache is allocated freshly each time a path_range_query is
allocated which makes this process (in case any global range is registered)
O(num-ssa-names) which for large functions can be very expensive.

None of the path_range_query CTORs supports sharing the cache (and I'm not
sure that would be "correct").  For the testcase at hand nearly all
ssa_global_cache objects are allocated from path_range_query and the
backwards threader.  But there are CTOR calls from the ranger_cache CTOR
as well - the backwards threader also has a ranger instance, so I wonder
if one can take the global cache from that (co-incidentially the path-range
query instance gets a reference to a ranger instance ...).

Maybe ssa_global_cache is just a very bad representation for the path
range query.