On 9/26/24 10:03, Andrew MacLeod wrote:
On 9/26/24 03:07, Richard Biener wrote:
On Wed, 25 Sep 2024, Andrew MacLeod wrote:
I added a note to the PR before I saw this... we can just disable
transitives
when the graph gets too big... I don't think they are worth the
expense when
things get large. I've attached that patch if you want to consider
it. It
probably should have been included when I added the switchover to
fast VRP,
but I wasn't thinking about ranger still being used by the threader.
That said, I'm also OK with your patch if you'd rather to go with it.
To comment here and not in the PR aboud simply disabling feature X when
"the CFG is too large" (or other metric) - I think we should try to be
more nuanced and apply limiting so there isn't a hard border on some
size metric where before GCC get's slower with increasing size and
after we're fast again but lousy to optimize even "cheap" cases.
IM not sure Id categorize it as "lousy" if we miss transitives in a
giant CFG, but sure, I get your point.
That said, my main issue right now is that DOM at -O1 is comparatively
very expensive on those testcases - if you look at a profile 98% of
it's time is spent in ranger code. Fortunately we do have
-fexpensive-optimizations, so we maybe want to use that to default
transitives but I'm also thinking whether it's possible to restrict
DOMs ranger processing to global ranges? DOM does enable_ranger ()
and not just it's range-query so I'm not sure I can easily subsitute
global range query?
Aldy added ranger to DOM as a stopgap on the path of removing EVRP,
and then the ultimate realization of this was to removing DOM itself.
There is very little DOM is doing that isn't taken care of with
rangers infrastructure.. I think the floating point support and some
minor additions to prange were all that stood in the way. Whether
that path will be pursued going forward IM not sure.
It looks like DOM is using GORI exports in
dom_opt_dom_walker::set_global_ranges_from_unreachable_edges () , but
all other uses of ranger appear to use the normal range_query API, so
thats the only ranger specific thing being used.
GORI has already been extracted from ranger and is a stand alone unit,
so instead of gimple-ranger *m_ranger = enable_ranger(), you could use
the global_range_query and a create a gori_ssa unit for it during DOM..
ie something like
range_query *m_ranger = get_global_range_query ();
m_ranger->create_gori ();
then there will be a normnal set of exports calculated as required...
And instead of disable_ranger (), call
m_ranger->destroy_gori ();
All in theory anyway.
Never mind... I was looking at it, and although the DOM walker doesn't
need it, there is also a path_query which unfortunately does still
require a full ranger :-P
I had some suggestions for how to impalement the path query class by
using the new gori_on_edge() interface to simply pick up ranges on edges
and that would speed it up and avoid ranger altogether... But alas,
another thing no one has gotten to.
Andrew
