------- 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
