[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #9 from jakub at gcc dot gnu dot org 2010-06-30 06:12 --- Subject: Bug 44694 Author: jakub Date: Wed Jun 30 06:12:22 2010 New Revision: 161587 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161587 Log: PR debug/44694 * cselib.h (cselib_preserve_cfa_base_value): Add regno argument. * cselib.c (cfa_base_preserved_regno): New static variable. (cselib_reset_table): Don't reset cfa_base_preserved_regno instead of REGNO (cfa_base_preserved_val-locs-loc). (cselib_preserve_cfa_base_value): Add regno argument, set cfa_base_preserved_regno to it. (cselib_invalidate_regno): Allow removal of registers other than cfa_base_preserved_regno from cfa_base_preserved_val. (cselib_finish): Set cfa_base_preserved_regno to INVALID_REGNUM. * var-tracking.c (adjust_mems): Replace sp or hfp even outside of MEM addresses, if not on LHS. (reverse_op): Don't add reverse ops for cfa_base_rtx. (vt_init_cfa_base): Adjust cselib_preserve_cfa_base_value caller. Modified: trunk/gcc/ChangeLog trunk/gcc/cselib.c trunk/gcc/cselib.h trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-29 06:28 --- The extremely long location lists are caused mainly by reverse_op created equivalences. Wonder whether we shouldn't on RHS replace sp and sp + const_int with framep and framep + const_int even outside of memory addresses and of course not do reverse_op if the register is framep - the framep is always computable, so it isn't useful to reverse it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-29 08:53 --- Created an attachment (id=21035) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21035action=view) gcc46-pr44694.patch With this patchlet the compile time on ginac.ii went down from more than 3 minutes to 16 seconds. The same number of DIEs as before have DW_AT_location, just .debug_loc got bigger, so need to investigate whether it is because the debug info is more completely, or if it is worse or just less compact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-29 09:09 --- readelf -wo ginac.o1 | grep 'End of' | wc -l; readelf -wo ginac.o2 | grep 'End of' | wc -l; readelf -wo ginac.o1 | wc -l; readelf -wo ginac.o2 | wc -l; readelf -wo ginac.o1 | grep fbreg | wc -l; readelf -wo ginac.o2 | grep fbreg | wc -l 11850 11796 351354 462546 8117 341790 As the number of DW_AT_location (and DW_AT_const_value) attributes in .debug_info is identical, the above means that with the patch 54 vars no longer use .debug_loc (which means they cover the whole function while before they didn't). For the tiny bit fewer location lists the patched version has more entries in many of them (which can still mean either that the coverage is better, or worse (there could be more holes)) and that DW_OP_fbreg is now used much more often than before (that is quite expected with this patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-29 14:11 --- Created an attachment (id=21039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21039action=view) gcc46-pr44694.patch Updated patch that actually passed bootstrap/regtested on x86_64-linux and i686-linux. When (frame) is present outside of MEM addresses, some tweaks to cselib are needed, otherwise it ICEs quite often. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #21035|0 |1 is obsolete|| 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=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-28 09:13 --- Confirmed. At -O2 -g we get for 4.4.x variable tracking : 0.26 ( 1%) usr 0.00 ( 0%) sys 0.24 ( 1%) wall 1870 kB ( 1%) ggc TOTAL : 26.74 1.1929.62 282737 kB while for the current 4.5 branch we have variable tracking : 392.60 (96%) usr 2.69 (73%) sys 397.72 (96%) wall 30099 kB (11%) ggc TOTAL : 409.66 3.69 415.97 279266 kB -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||compile-time-hog Last reconfirmed|-00-00 00:00:00 |2010-06-28 09:13:08 date|| Summary|[4.4 4.5 regression] Long |[4.5/4.6 Regression] Long |var tracking compile time of|var tracking compile time of |GiNaC tests |GiNaC tests Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-28 09:13 --- Created an attachment (id=21023) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21023action=view) unincluded testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-28 16:12 --- Seems the problem here is extremely long loc_chain lists (the longest one in insert_into_intersection has 3740 entries), so e.g. insert_into_intersection is extremely time consuming. Most of the locations in the long lists are of the form (plus:DI (value:DI ...) (const_int ...)) with different values and offsets. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
