[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #22 from dcb314 at hotmail dot com 2010-05-16 10:21 --- (In reply to comment #21) Assuming this is fixed. If you have a new testcase, please file a new PR. I am not sure that my original bug report is fixed. I tried 4.6 snapshot 20100515 and it couldn't compile it in ten minutes (ulimit -t 600) on a 2.7GHz Athlon. -- dcb314 at hotmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #21 from jakub at gcc dot gnu dot org 2010-03-18 20:36 --- Assuming this is fixed. If you have a new testcase, please file a new PR. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #19 from jakub at gcc dot gnu dot org 2010-03-15 15:12 --- A variant of the #c9 patch is checked in for many days, do you still have something where VTA is really so big compile time or memory hog (besides PR43058)? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-03-15 15:20 --- *** Bug 42911 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #18 from aoliva at gcc dot gnu dot org 2010-03-06 20:26 --- Subject: Bug 41371 Author: aoliva Date: Sat Mar 6 20:26:15 2010 New Revision: 157257 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157257 Log: * var-tracking.c (dataflow_set_merge): Swap src and src2. Reverted: 2010-01-13 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (values_to_unmark): New variable. (find_loc_in_1pdv): Clear VALUE_RECURSED_INTO of values in values_to_unmark vector. Moved body to... (find_loc_in_1pdv_1): ... this. Don't clear VALUE_RECURSED_INTO, instead queue it into values_to_unmark vector. (vt_find_locations): Free values_to_unmark vector. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #16 from l dot lunak at suse dot cz 2010-02-16 12:47 --- Created an attachment (id=19887) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19887action=view) testcase from kdesdk/umbrello If it helps, here's another testcase where 2G RAM is not enough. This is g++ (SUSE Linux) 4.5.0 20100212 (experimental) [trunk revision 156733] on x86_64 with -g -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #17 from jakub at gcc dot gnu dot org 2010-02-16 13:06 --- You should retry with r156794 or newer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #15 from jakub at gcc dot gnu dot org 2010-01-19 09:03 --- This patch seems to fix issues with (most of) KDE testcases, but there are still some testcases where gcc spends very long time in var-tracking (usually generated huge routines where simply too many VALUEs are tracked through). E.g. https://bugzilla.redhat.com/show_bug.cgi?id=548826 and https://bugzilla.redhat.com/show_bug.cgi?id=531218 These can be worked around by the #c9 patch, even with much bigger default (50mil). Not sure if we should track this all in this bug, or just split into separate bugs. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #14 from jakub at gcc dot gnu dot org 2010-01-13 13:27 --- Subject: Bug 41371 Author: jakub Date: Wed Jan 13 13:26:47 2010 New Revision: 155858 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155858 Log: PR debug/41371 * var-tracking.c (values_to_unmark): New variable. (find_loc_in_1pdv): Clear VALUE_RECURSED_INTO of values in values_to_unmark vector. Moved body to... (find_loc_in_1pdv_1): ... this. Don't clear VALUE_RECURSED_INTO, instead queue it into values_to_unmark vector. (vt_find_locations): Free values_to_unmark vector. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-12 09:09 --- (In reply to comment #10) I've looked briefly at the #c4 testcase, and the problem seems to be extremely long loc_chains. var-tracking e.g. stops for huge amount of time (many minutes) on one bb, EH pad with 162 incoming EH edges (and no others). Each of those 162 incoming EH edges has roughly 1800 vars in its out hash table, with just one problematic one - which has around 650 items in var-var_part[0].loc_chain chain. There are ~ 2 other vars with loc_chain chain lengths in the 40s and the rest is with chain length below 10. The CPU eater is intersect_loc_chains. For each of the 650 loc_chain entries it calls find_loc_in_1pdv, which, as the vast majority of the entries in s2var's loc_chain are VALUEs, looks stuff up in the hash table and recurses. I wonder whether for large loc_chain lengths we just couldn't use a temporary hash table. If we see in intersect_loc_chains that chain length is beyond certain threshold, populate a temporary hash table by doing what find_loc_in_1pdv does (except instead of rtx_equal_p and returning early it seeing a match it would record each loc into the hash table and continue walking). Then intersect_loc_chains could just walk this hash table instead of searching through it again and again, avoiding the O(loc_chain_length^2) complexity. That sounds like a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #12 from jakub at gcc dot gnu dot org 2010-01-12 12:58 --- It is actually far worse on this testcase, as with all the recursions find_loc_in_1pdv does we actually must scan many values many times. I've put a counter and on this bb one outermost find_loc_in_1pdv calls together rtx_equal_p roughly 88 times, times 650. So, perhaps even just not resetting VALUE_RECURSED_INTO back immediately, but in a second loop afterwards would be enough to make this manageable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #13 from jakub at gcc dot gnu dot org 2010-01-12 17:00 --- Created an attachment (id=19564) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19564action=view) gcc45-pr41371.patch Patch that speeds up the qmc2main.ii testcase to bearable compile time (2m20s on my box with -g -O2). With -g0 -O2 it compiles in 45s, so var-tracking still dominates the time, but it is no longer so slow. I'll bootstrap/regtest it now. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-11 18:23 --- I've looked briefly at the #c4 testcase, and the problem seems to be extremely long loc_chains. var-tracking e.g. stops for huge amount of time (many minutes) on one bb, EH pad with 162 incoming EH edges (and no others). Each of those 162 incoming EH edges has roughly 1800 vars in its out hash table, with just one problematic one - which has around 650 items in var-var_part[0].loc_chain chain. There are ~ 2 other vars with loc_chain chain lengths in the 40s and the rest is with chain length below 10. The CPU eater is intersect_loc_chains. For each of the 650 loc_chain entries it calls find_loc_in_1pdv, which, as the vast majority of the entries in s2var's loc_chain are VALUEs, looks stuff up in the hash table and recurses. I wonder whether for large loc_chain lengths we just couldn't use a temporary hash table. If we see in intersect_loc_chains that chain length is beyond certain threshold, populate a temporary hash table by doing what find_loc_in_1pdv does (except instead of rtx_equal_p and returning early it seeing a match it would record each loc into the hash table and continue walking). Then intersect_loc_chains could just walk this hash table instead of searching through it again and again, avoiding the O(loc_chain_length^2) complexity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-05 22:30 --- Created an attachment (id=19478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19478action=view) vta-limit-on-size.patch While Alex is busy working on speeding up var-tracking on these KDE testcases, here is a temporary workaround, just giving up on -fvar-tracking-assignments if var-tracking would need too much memory/would take too long, and giving up on -fvar-tracking altogether if even that didn't help. 500 is something I came up from playing with cc1files on x86_64-linux with -O2 -g or -O3 -g. There is one generated routine in GCC which needs 1000 (recog_35 in the cc1files I have), otherwise all of SPEC2K, MICO, FF3D, rest of GCC, TRAMP3D etc. need always below 5mil (just tramp3d and one routine in ff3d is approaching it). Using 10mil is too much for the second testcase in this PR, had to break the build after 27 minutes. But with the 5mil limit it was quite quick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-02 15:05 --- *** Bug 42565 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aanisimov at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
