On Thu, 26 Sep 2024, Andrew MacLeod wrote: > > 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.
Yeah, it looks like major work for a pass that's still supposed to be go away ... so I'll continue to mostly plug those -O1 compile-time-hog holes. Richard.
