[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #41 from aoliva at gcc dot gnu dot org 2010-06-10 16:44 --- Subject: Bug 41371 Author: aoliva Date: Thu Jun 10 16:43:46 2010 New Revision: 160559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160559 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Remove recursion, only tail-recurse into canonical node. Fast-forward over non-canonical VALUEs. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #42 from aoliva at gcc dot gnu dot org 2010-06-10 17:01 --- Subject: Bug 41371 Author: aoliva Date: Thu Jun 10 17:01:32 2010 New Revision: 160563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160563 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Remove recursion, only tail-recurse into canonical node. Fast-forward over non-canonical VALUEs. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #40 from aoliva at gcc dot gnu dot org 2010-06-09 04:56 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #30 from jakub at gcc dot gnu dot org 2010-06-04 09:02 --- Created an attachment (id=20833) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20833action=view) rh598310.i.bz2 Another testcase from wine, ./cc1 -m32 -fPIC -fno-strict-aliasing -g -O2 rh598310.i -quiet takes here over 7 minutes, again most of the time spent in find_loc_in_1pdv called from intersect_loc_chains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #31 from jakub at gcc dot gnu dot org 2010-06-04 09:24 --- Created an attachment (id=20834) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20834action=view) limit-depth.patch Quick patch that brings the time down to 1 minute 15 sec. From the callgrind dump on this testcase, intersect_loc_chains in 5159260x cases calls insert_into_intersection in the first loop (i.e. where the recent patch from this PR helps), then calls 320611x find_loc_in_1pdv. Out of these calls, 75537x it returns NULL and the rest of time it returns non-NULL. When it returns non-NULL, it is possible to return non-NULL without recursion 244863x, with one level of find_loc_in_1pdv recursion 205x and with two level recursion 6x. No successful call in this testcase needs deeper recursion. When not limiting the recursion depth, instead just monitoring it, for all cases where find_loc_in_1pdv returned non-NULL the depth at which return node; is used is at most 2 (0 is just find_loc_in_1pdv call with no recursion) and maximum depth ever recursed for the successful calls is 3. I believe the problem of this testcase is not the cases where find_loc_in_1pdv returns non-NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #32 from jakub at gcc dot gnu dot org 2010-06-04 09:30 --- Created an attachment (id=20835) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20835action=view) hack Hack that shows that the maximum depth is 3 even for the found == NULL cases. Alex tells me on IRC he has the right fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #33 from aoliva at gcc dot gnu dot org 2010-06-04 09:51 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #34 from aoliva at gcc dot gnu dot org 2010-06-04 10:03 --- Created an attachment (id=20836) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20836action=view) Patch that fixes the bug and verifies recursion is bounded as expected This patch (except for comments and ChangeLog) completed stage1 libs, more testing needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-06-04 11:03 --- Created an attachment (id=20837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20837action=view) bnc611650 Another testcase from open-office this time, on i?86-linux only. $ time g++ -c -g -Os -fomit-frame-pointer analysis.ii real103m46.642s user96m21.093s sys 0m1.196s $ time g++ -c -g -Os analysis.ii real0m19.345s user0m19.177s sys 0m0.168s $ time g++ -c -Os -fomit-frame-pointer analysis.ii real0m3.747s user0m3.640s sys 0m0.104s numbers above are from the 4.5 branch rev. 159866. trunk is also very slow, but the compile didn't yet finish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #36 from jakub at gcc dot gnu dot org 2010-06-04 11:15 --- With Alex' patch with checking guarded with #ifdef ENABLE_CHECKING (currently bootstrapping/regtesting that) I see on x86_64 on the trunk: time ./cc1plus -m32 -quiet -g -Os -fomit-frame-pointer bug-611650_analysis.ii real2m16.789s user2m16.333s sys 0m0.276s Of course not ideal, but much better than those 103 minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-06-04 12:45 --- Subject: Bug 41371 Author: rguenth Date: Fri Jun 4 12:44:41 2010 New Revision: 160261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160261 Log: 2010-06-04 Richard Guenther rguent...@suse.de Backport from mainline: 2010-05-18 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Add a few checks from rtx_equal_p inline. 2010-05-25 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Guard asserts with ENABLE_CHECKING. (intersect_loc_chains): Walk the s2var's loc_chain together with s1node chain as long as the locations are equal, don't call find_loc_in_1pdv in that case. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #38 from jakub at gcc dot gnu dot org 2010-06-04 16:42 --- Subject: Bug 41371 Author: jakub Date: Fri Jun 4 16:42:27 2010 New Revision: 160280 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160280 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Mark initial value before recursing. Check that recursion is bounded. Rename inner var to avoid hiding incoming argument. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #39 from jakub at gcc dot gnu dot org 2010-06-04 16:48 --- Subject: Bug 41371 Author: jakub Date: Fri Jun 4 16:47:41 2010 New Revision: 160282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160282 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Mark initial value before recursing. Check that recursion is bounded. Rename inner var to avoid hiding incoming argument. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #28 from jakub at gcc dot gnu dot org 2010-05-25 10:39 --- Created an attachment (id=20741) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20741action=view) gcc46-pr41371.patch Another small optimization. At least on this testcase in 80% the s1node and s2var-var_part[0].loc_chain chains contain the same locations in the same order. So, if we avoid calling find_loc_in_1pdv in that case and only start calling it when they differ, the testcase can be speeded up slightly. With --enable-checking=release cc1plus the difference is: real4m52.484s user4m51.991s sys 0m0.446s to: real3m38.218s user3m37.641s sys 0m0.383s I'm going to bootstrap/regtest it now with additional statistics gathering on how many find_loc_in_1pdv calls it can avoid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #29 from jakub at gcc dot gnu dot org 2010-05-25 16:27 --- Subject: Bug 41371 Author: jakub Date: Tue May 25 16:27:03 2010 New Revision: 159829 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159829 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Guard asserts with ENABLE_CHECKING. (intersect_loc_chains): Walk the s2var's loc_chain together with s1node chain as long as the locations are equal, don't call find_loc_in_1pdv in that case. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-18 09:36 --- Subject: Bug 41371 Author: jakub Date: Tue May 18 09:35:52 2010 New Revision: 159528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159528 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Add a few checks from rtx_equal_p inline. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #26 from rguenth at gcc dot gnu dot org 2010-05-17 14:28 --- The problem from comment #12 seems to be back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-05-16 10:49 --- I see variable tracking : 734.06 (99%) usr 0.33 (35%) sys 735.29 (99%) wall 11548 kB ( 8%) ggc ... 743.18user 1.00system 12:25.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+10440outputs (0major+116553minor)pagefaults 0swaps for bug90.cc at -O2 -g with 4.5 branch r158342. Which is a 6800% regression over 4.4.3: 10.88user 0.62system 0:12.64elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k 18664inputs+5096outputs (106major+55648minor)pagefaults 0swaps -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P1 |P2 Last reconfirmed|2009-10-18 18:00:22 |2010-05-16 10:49:29 date|| Summary|[4.5 Regression] var- |[4.5/4.6 Regression] var- |tracking is slow and memory |tracking is slow and memory |hungry |hungry Target Milestone|4.5.0 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #24 from pluto at agmk dot net 2010-05-16 12:22 --- *** Bug 43776 has been marked as a duplicate of this bug. *** -- pluto at agmk dot net changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #25 from pluto at agmk dot net 2010-05-16 12:26 --- PR43776 constains another thestcase: results for top of 4.5/4.6: $ time g++45 -Wall -c 1.ii -O1 -g2 1.ii: In member function 'void es::ClockAnalyzer::initPrimitives()': 1.ii:38722:7: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without g++45 -Wall -c 1.ii -O1 -g2 32,72s user 0,35s system 99% cpu 33,096 total $ time g++46 -Wall -c 1.ii -O1 -g2 1.ii: In member function 'void es::ClockAnalyzer::initPrimitives()': 1.ii:38722:7: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without g++46 -Wall -c 1.ii -O1 -g2 23,68s user 0,40s system 99% cpu 24,099 total btw. the '-O1 -fno-inline -g2' has worse results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
