[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #42 from Richard Biener --- Fixed as far as I am concerned.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #41 from Richard Biener --- Author: rguenth Date: Mon Jun 24 17:19:36 2019 New Revision: 272622 URL: https://gcc.gnu.org/viewcvs?rev=272622=gcc=rev Log: 2019-06-24 Richard Biener PR tree-optimization/90930 PR tree-optimization/90316 * tree-ssa-alias.c (walk_non_aliased_vuses): Add missing decrement of limit. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/tree-ssa-alias.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #40 from Richard Biener --- Author: rguenth Date: Mon Jun 24 17:17:26 2019 New Revision: 272621 URL: https://gcc.gnu.org/viewcvs?rev=272621=gcc=rev Log: 2019-06-24 Richard Biener PR tree-optimization/90930 PR tree-optimization/90316 * tree-ssa-alias.c (walk_non_aliased_vuses): Add missing decrement of limit. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #39 from Richard Biener --- Author: rguenth Date: Fri May 17 08:10:58 2019 New Revision: 271314 URL: https://gcc.gnu.org/viewcvs?rev=271314=gcc=rev Log: 2019-05-17 Richard Biener Backport from mainline 2019-05-07 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.h (get_continuation_for_phi): Take walking limit by reference. (walk_non_aliased_vuses): Take walking limit argument. * tree-ssa-alias.c (maybe_skip_until): Take limit and abort walking if it is reached instead of just counting. (get_continuation_for_phi): Likewise. (walk_non_aliased_vuses): Likewise, instead of leaving counter limiting to the callback. * tree-ssa-sccvn.c (vn_reference_lookup_2): Adjust. (vn_reference_lookup_3): Likewise. (vn_reference_lookup_pieces): Likewise. (vn_reference_lookup): Likewise. * tree-ssa-pre.c (translate_vuse_through_block): Limit walking. * tree-ssa-scopedtables.c (vuse_eq): Adjust. (avail_exprs_stack::lookup_avail_expr): Likewise. 2019-05-06 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.c (maybe_skip_until): Pass in target BB, compute target on demand. (get_continuation_for_phi): Remove code walking stmts to get to a target virtual operand which could end up being quadratic. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/tree-ssa-alias.c branches/gcc-9-branch/gcc/tree-ssa-alias.h branches/gcc-9-branch/gcc/tree-ssa-pre.c branches/gcc-9-branch/gcc/tree-ssa-sccvn.c branches/gcc-9-branch/gcc/tree-ssa-scopedtables.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #38 from Richard Biener --- (In reply to Than McIntosh from comment #37) > (In reply to rguent...@suse.de from comment #36) > > > Thanks for the experiment. I guess I will limit backporting things > > to the GCC 9 branch then. Am I correct that the 2127 seconds are > > the same regardless of whether r271124 is applied to the branch or not? > > The patch makes things slightly better -- without it the time is 2540 > seconds. OK, so I am going to backport r270902 and r270940 to fix the introduced quadraticness and make limiting effective to the GCC 9 branch but not further since it may uncover other issues through code-gen changes caused by r270902 and the issue wasn't noticed until now. I'm considering the other two revs as well but only after some additional soaking time.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #37 from Than McIntosh --- (In reply to rguent...@suse.de from comment #36) > Thanks for the experiment. I guess I will limit backporting things > to the GCC 9 branch then. Am I correct that the 2127 seconds are > the same regardless of whether r271124 is applied to the branch or not? The patch makes things slightly better -- without it the time is 2540 seconds.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #36 from rguenther at suse dot de --- On Tue, 14 May 2019, thanm at google dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 > > --- Comment #35 from Than McIntosh --- > I applied r271124 to the gcc-9 branch and re-ran the large testcase -- still > has the long compile time (2127 seconds), FWIW. Thanks for the experiment. I guess I will limit backporting things to the GCC 9 branch then. Am I correct that the 2127 seconds are the same regardless of whether r271124 is applied to the branch or not?
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #35 from Than McIntosh --- I applied r271124 to the gcc-9 branch and re-ran the large testcase -- still has the long compile time (2127 seconds), FWIW.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #34 from Than McIntosh --- GCC 8 and 9 branches -- I'll do that experiment later this morning. It's worth noting that if the code in questing uses more modern Go constructs (things introduced in Go 1.11/1.12) it may not compile properly, but I will at least give it a shot.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #33 from Richard Biener --- (In reply to Than McIntosh from comment #32) > Compile time for the larger example looks good for the most recent commit on > trunk (271124), ~130 seconds. Thanks for all your help on this. Great! Can you verify whether just this commit (r271124) applied ontop of the GCC 9 branch has a similar result? That's the most safe single commit to backport (also to the GCC 8 branch where it applies as well, so bonus if you can check there, too).
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #32 from Than McIntosh --- Compile time for the larger example looks good for the most recent commit on trunk (271124), ~130 seconds. Thanks for all your help on this.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #31 from Richard Biener --- Author: rguenth Date: Mon May 13 11:22:21 2019 New Revision: 271124 URL: https://gcc.gnu.org/viewcvs?rev=271124=gcc=rev Log: 2019-05-13 Richard Biener PR tree-optimization/90316 * tree-ssa-pre.c (insert_aux): Fold into ... (insert): ... this function. Use a RPO walk to reduce the number of required iterations. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #30 from Richard Biener --- Created attachment 46347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46347=edit incremental patch Unfortunately the 46339 attachment failed during bootstrap compare. The attached one incrementally changes the iteration scheme from dominator-based to RPO-based which should strictly interate less. If that provides a reasonable speedup on its own it would be also a candidate for backporting.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #29 from Than McIntosh --- Tested patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=46337 and that brings compile time now down to about 700 seconds. -ftime-report shows that tree-PRE is still the major culprit. Also tested second patch at https://gcc.gnu.org/bugzilla/attachment.cgi?id=46339 and that looks even better, reduces compile time to 137 seconds, which is well under the timeout enforced by our build system. Thanks--
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #28 from Richard Biener --- Created attachment 46339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46339=edit untested patch This is another patch. It changes the iteration scheme to RPO order instead of DOM order to not require iteration unless AVAIL_OUT changes on a backedge (which usually should not happen for regular PRE insertions...). Your reduced testcases were all acyclic so this should fix the slowness there.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #27 from Richard Biener --- Created attachment 46337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46337=edit untested patch So this is another patch adjusting PRE insertion to only iterate when necessary (well, I think it should be never necessary to iterate...). That said, it strips iteration down to a minimum (still supporting the notion that iteration is necessary at all). I wonder if iteration in the end is really only because of the sorting order issue, thus if the patch doesn't help, can you try changing the hunk @@ -3326,6 +3331,10 @@ do_pre_regular_insertion (basic_block bl } } } + /* ??? Imperfect sorting of expressions means we have to iterate here. + For example gcc.dg/tree-ssa/pr23455.c shows a dependent memory + load cannot be inserted as part of a computation. */ + } while (old_trans_fails != trans_fails); exprs.release (); return new_stuff; to never loop and try again? (this particular looping is a hack implementation-wise and probably can be improved or even avoided)
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #26 from Richard Biener --- (In reply to Richard Biener from comment #25) > OK, so the hashtable looks good. But > > 135 pre "insert iterations == 1084" 1 > > is indeed excessive. Expecially combined with > > 135 pre "Insertions" 3 Ah, but 135 pre "New PHIs" 1085 so we're inserting a PHI per iteration appearantly... :/ > I wonder if you can share the full -fdump-tree-pre-details dump (it's > going to be large though). So the insertion possibly excessively iterates.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #25 from Richard Biener --- OK, so the hashtable looks good. But 135 pre "insert iterations == 1084" 1 is indeed excessive. Expecially combined with 135 pre "Insertions" 3 I wonder if you can share the full -fdump-tree-pre-details dump (it's going to be large though).
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #24 from Than McIntosh --- Did another run with the patch from comment 21. For the offending routine I get: phi-translate cache statistics: size 2097143, 1171808 elements, 0.465610 collisions
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #23 from Than McIntosh --- Created attachment 46326 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46326=edit dump from -fdump-statistics-stats
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #22 from Than McIntosh --- Apologies for the delayed response (busy with other bugs yesterday). Testcase: hard to share the original... it has hundreds if not thousands of imported packages (it's an auto-generated Go file), and I'd have to figure out some way to sanitize all the identifiers, since there is a lot of Google-proprietary stuff there. I'm attaching the output of -fdump-statistics-stats. The insert iterations lines are: 135 pre "insert iterations == 1084" 1 135 pre "insert iterations == 1" 9 135 pre "insert iterations == 2" 1
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #21 from Richard Biener --- It also looks the hash_table hash function is weak judging from the time spent in the equality routine. Index: gcc/tree-ssa-pre.c === --- gcc/tree-ssa-pre.c (revision 271000) +++ gcc/tree-ssa-pre.c (working copy) @@ -4118,6 +4118,12 @@ fini_pre () bitmap_obstack_release (_bitmap_obstack); bitmap_set_pool.release (); pre_expr_pool.release (); + if (dump_file && (dump_flags & TDF_DETAILS)) +fprintf (dump_file, "phi-translate cache statistics: " +"size %ld, %ld elements, %f collisions\n", +(long) phi_translate_table->size (), +(long) phi_translate_table->elements (), +phi_translate_table->collisions ()); delete phi_translate_table; phi_translate_table = NULL; delete expression_to_id; should help verify that if you then do a -fdump-tree-pre-details and look into the respective generated dump file. Similar for get_expr_value_id? But that one should be cheap so I am a bit confused about this profile graph.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #20 from Richard Biener --- (In reply to Than McIntosh from comment #19) > Created attachment 46313 [details] > SVG graph from profiling run Do I read this correctly in that all the time spent in PRE is via do_pre_regular_insertion? Or is the profiling imperfect in that the times on get_continuation_for_phi show all invocations of it, not just those via the graph edges coming ultimatively from do_pre_regular_insertion? It looks like we are doing a disproportionally big number of insert iterations here - if you compile with -fdump-statistics-stats you'll get a .statistics dump file showing lines with "insert iterations", can you quote those? (maybe attach this statistics file) On the testcases attached here we do not insert anything btw. I guess you can't really share the original testcase?
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #19 from Than McIntosh --- Created attachment 46313 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46313=edit SVG graph from profiling run
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #18 from Than McIntosh --- I tested the most recent commit (270944). That cuts the compile time on the larger example in half, but still at around 1200 seconds. I took another profile (will attach an SVG image from 'pprof web').
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #17 from Richard Biener --- Author: rguenth Date: Tue May 7 13:03:19 2019 New Revision: 270944 URL: https://gcc.gnu.org/viewcvs?rev=270944=gcc=rev Log: 2019-05-07 Richard Biener PR tree-optimization/90316 * tree-ssa-pre.c (translate_vuse_through_block): When same_valid is NULL do not bother to search for a virtual PHI continuation. (phi_translate_1): When operands changed we cannot keep the same value-number so do not bother to ask whether that's possible from translate_vuse_through_block. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #16 from Richard Biener --- Author: rguenth Date: Tue May 7 11:17:00 2019 New Revision: 270940 URL: https://gcc.gnu.org/viewcvs?rev=270940=gcc=rev Log: 2019-05-07 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.h (get_continuation_for_phi): Take walking limit by reference. (walk_non_aliased_vuses): Take walking limit argument. * tree-ssa-alias.c (maybe_skip_until): Take limit and abort walking if it is reached instead of just counting. (get_continuation_for_phi): Likewise. (walk_non_aliased_vuses): Likewise, instead of leaving counter limiting to the callback. * tree-ssa-sccvn.c (vn_reference_lookup_2): Adjust. (vn_reference_lookup_3): Likewise. (vn_reference_lookup_pieces): Likewise. (vn_reference_lookup): Likewise. * tree-ssa-pre.c (translate_vuse_through_block): Limit walking. * tree-ssa-scopedtables.c (vuse_eq): Adjust. (avail_exprs_stack::lookup_avail_expr): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-ssa-scopedtables.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #15 from Richard Biener --- Created attachment 46310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46310=edit untested patch So on it's own that doesn't help, after changing this --param sccvn-max-alias-queries-per-access makes a difference though (it doesn't before). It's default is somewhat high at 1000, IIRC I chose a default limit that didn't trigger during GCC bootstrap back in time. The refactoring would also enable to assign an overall budget rather than a per access one. Can you try the patch on the original testcase? (it doesn't apply 100% to the GCC 8 branch but I guess you'll manage to do that manually in case needed) On your attached testcase it doesn't make a (big) difference unless you lower --param sccvn-maxa-alias-queries-per-access. I will poke a bit more.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #14 from Richard Biener --- 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.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #13 from Than McIntosh --- I've made a stab at revising the test case to try to trigger the long compile time that I'm still seeing the real application code. Still not quite there yet (revised testcase takes maybe a minute to compile, original 45 mins) -- I don't understand quite why. To compile the revised testcase: gccgo -g -c -O2 auxiliary.go gccgo -g -c -O2 -I . generated2.go Having more than one package seems to be part of the equation (changes aliasing in some way? hard to tell). Profile still seems to be pointing to the same routines as before: (pprof) top15 Showing nodes accounting for 41.67s, 83.29% of 50.03s total Dropped 986 nodes (cum <= 0.25s) Showing top 15 nodes out of 88 flat flat% sum%cum cum% 15.12s 30.22% 30.22% 17.43s 34.84% dominated_by_p 7.96s 15.91% 46.13% 33.78s 67.52% get_continuation_for_phi 4.05s 8.10% 54.23% 4.05s 8.10% canon_value_cmp (inline) 3.70s 7.40% 61.62% 8.35s 16.69% canonicalize_values_star 2.31s 4.62% 66.24% 2.31s 4.62% dom_convert_dir_to_idx (inline) 2.29s 4.58% 70.82% 2.29s 4.58% tree_check (inline) 1.34s 2.68% 73.50% 4.25s 8.49% set_slot_part 1.11s 2.22% 75.71% 1.15s 2.30% gimple_vuse (inline) 1.05s 2.10% 77.81% 1.05s 2.10% loc_cmp 0.64s 1.28% 79.09% 0.64s 1.28% bitmap_list_find_element (inline) 0.52s 1.04% 80.13% 0.88s 1.76% hash_table::find_slot_with_hash
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #11 from Than McIntosh --- Created attachment 46303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46303=edit modified test case (file 1 of 2)
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #12 from Than McIntosh --- Created attachment 46304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46304=edit modified test case (file 2 of 2)
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #10 from Than McIntosh --- Update: it looks like we are not out of the woods quite yet -- I am seeing some similar behavior farther into the build. I will try to produce another reduced test case (this one is proving more difficult replicate).
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon May 6 08:54:40 2019 New Revision: 270902 URL: https://gcc.gnu.org/viewcvs?rev=270902=gcc=rev Log: 2019-05-06 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.c (maybe_skip_until): Pass in target BB, compute target on demand. (get_continuation_for_phi): Remove code walking stmts to get to a target virtual operand which could end up being quadratic. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] large |[8/9 Regression] large |compile time increase in|compile time increase in |opt / alias stmt walking|opt / alias stmt walking |for Go example |for Go example --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
