https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Trunk:
tree PRE : 23.45 ( 58%) 0.18 ( 60%) 23.93 ( 58%)
17811 kB ( 29%)
`- tree tail merge : 0.03 ( 0%) 0.00 ( 0%) 0.02 ( 0%)
197 kB ( 0%)
`- alias stmt walking : 11.19 ( 27%) 0.04 ( 13%) 10.95 ( 27%)
0 kB ( 0%)
`- tree PTA : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%)
16 kB ( 0%)
gcc 8 with the patch:
tree PRE : 26.65 ( 46%) 0.19 ( 46%) 30.98 ( 49%)
17935 kB ( 28%)
`- alias stmt walking : 12.43 ( 22%) 0.08 ( 20%) 14.08 ( 22%)
0 kB ( 0%)
`- tree tail merge : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%)
197 kB ( 0%)
`- tree CFG cleanup : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%)
0 kB ( 0%)
`- tree PTA : 0.03 ( 0%) 0.00 ( 0%) 0.03 ( 0%)
16 kB ( 0%)
so this is in-line with the previous testcase and nowhere near minutes?
When I start with Name/V[0, 4] and double to Name/V[0,8] I go from
438 to 864 calls to get_continuation_for_phi and from 654 to 1260
calls to maybe_skip_until, similarly dominated_by_p calls double
so there doesn't seem to be any quadraticness here either.
It's true the walk limiting doesn't kick in for the work done by
get_continuation_for_phi but only at the first lookup after that
finished, wasting cycles. I'll see if changing that improves
things here, but the work limit per query is quite high here.
