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.
