On 04/05/2018 06:32 AM, Richard Biener wrote: > > This fixes exponential time spent in find_base_term by extending the > existing fix of NULL-ifying VALUE locations during their processing > to keep them NULL-ified during the whole recursion. > > As Jakub figured this has the chance of returning NULL prematurely > for the case of the plus/minus case rejecting a found base on the > ground of > > if (base != NULL_RTX > && ((REG_P (tmp1) && REG_POINTER (tmp1)) > || known_base_value_p (base))) > return base; > > so any VALUE visited during a such rejected base will not be > visited again (but we'll get a NULL result). > > Quoting him from IRC: still no differences, out of 850mil calls > > for an instrumented version. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Alternative (safer in the above regard) variants using a hash-map > to cache the base for a VALUE are quite a bit slower if not implemented > in ways that also look dangerous at this point. See the PR for > some of those. > > Any comments? Otherwise we decided to go ahead with this tomorrow. > > Thanks, > Richard. > > 2018-04-05 Richard Biener <rguent...@suse.de> > > PR middle-end/85180 > * alias.c (find_base_term): New wrapper around find_base_term > unwinding CSELIB_VAL_PTR changes. > (find_base_term): Do not restore CSELIB_VAL_PTR during the > recursion. > > * gcc.dg/pr85180.c: New testcase. Seems reasonable. I do wonder how much all the complexity in alias.c buys us these days and whether or not we should look to do some dramatic simplifications. The core parts of this code date back to the late 90s when RTL memory disambiguation was much more important than it is today.