This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
- From: "jakub at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 5 Jan 2010 22:30:42 -0000
- Subject: [Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
- References: <bug-41371-9596@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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=19478&action=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.
5000000 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 10000000
(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