[Bug c++/43632] New: -g option became very slow after r157834

[Bug c++/43632] New: -g option became very slow after r157834

[roman at binarylife dot net]

$ svn up -r157834 ~/src/gcc
...
$ make -C ~/src/gcc install
...
$ time g++ -std=c++0x -O2 -c test.cpp -g
real    4m47.882s
user    4m47.226s
sys     0m0.577s
$ time g++ -std=c++0x -O2 -c test.cpp
real    0m28.247s
user    0m27.935s
sys     0m0.282s

For comparison:

$ svn up -r157833 ~/src/gcc
...
$ make -C ~/src/gcc install
...
$ time g++ -std=c++0x -O2 -c test.cpp -g
real    0m38.055s
user    0m37.476s
sys     0m0.475s
$ time g++ -std=c++0x -O2 -c test.cpp 
real    0m28.149s
user    0m27.861s
sys     0m0.278s


-- 
           Summary: -g option became very slow after r157834
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: roman at binarylife dot net
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug c++/43632] -g option became very slow after r157834

[roman at binarylife dot net]

------- Comment #1 from roman at binarylife dot net  2010-04-02 19:42 -------
Created an attachment (id=20293)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20293&action=view)
test.cpp


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug c++/43632] -g option became very slow after r157834

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2010-04-02 20:24 -------
The function is huge, > 2000 basic blocks, tracking almost 7000 preserved
VALUEs.  Most of the time is spent in vt_find_locations (understandably with so
many bbs), but the hash table sizes don't grow quickly enough to trigger
maximum hash table size limit.  You can certainly compile with --param
max-vartrack-size=10000000 or something similar, or
-fno-var-tracking-assignments as a workaround.


-- 

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

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2010-04-02 20:26 -------
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |rtl-optimization
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-02 20:26:03
               date|                            |
            Summary|-g option became very slow  |[4.5 Regression] -g option
                   |after r157834               |became very slow after
                   |                            |r157834
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2010-04-02 21:03 -------
Another datapoint: I now get

WARNING: program timed out.
FAIL: gcc.c-torture/compile/limits-fnargs.c  -O3 -g  (test for excess errors)

consistently on a somewhat old machine.  It hadn't showed up for months
(years?).


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2010-04-06 10:07 -------
callgrind --inclusive=yes says on this:
  438,822,838,411 
/usr/src/gcc/obj/gcc/../../gcc/var-tracking.c:variable_tracking_main
  429,638,024,208 
/usr/src/gcc/obj/libiberty/../../libiberty/hashtab.c:htab_traverse_noresize
[/usr/src/gcc/obj/gcc/cc1plus]
  428,305,658,767 
/usr/src/gcc/obj/libiberty/../../libiberty/hashtab.c:htab_traverse
[/usr/src/gcc/obj/gcc/cc1plus]
  417,506,443,433  ../../gcc/var-tracking.c:vt_find_locations
[/usr/src/gcc/obj/gcc/cc1plus]
  389,486,317,740  ../../gcc/var-tracking.c:dataflow_set_merge
[/usr/src/gcc/obj/gcc/cc1plus]
  389,242,104,098 
/usr/src/gcc/obj/gcc/../../gcc/var-tracking.c:variable_merge_over_cur
  389,242,104,098  ../../gcc/var-tracking.c:variable_merge_over_cur
[/usr/src/gcc/obj/gcc/cc1plus]
  345,572,722,020  ../../gcc/var-tracking.c:intersect_loc_chains
[/usr/src/gcc/obj/gcc/cc1plus]
  292,844,158,243  ../../gcc/var-tracking.c:find_loc_in_1pdv
[/usr/src/gcc/obj/gcc/cc1plus]
  117,800,020,698  /usr/src/gcc/obj/gcc/../../gcc/rtl.c:rtx_equal_p
  117,800,020,698  ../../gcc/rtl.c:rtx_equal_p [/usr/src/gcc/obj/gcc/cc1plus]
   78,786,470,332 
/usr/src/gcc/obj/libiberty/../../libiberty/hashtab.c:htab_find_with_hash
[/usr/src/gcc/obj/gcc/cc1plus]

so, as a micro-optimization what could work is use the spare bits in
location_chain_def (30 bits on 32-bit hosts, 32 + 30 bits on 64-bit hosts) for
something we could compare quickly in place of rtx_equal_p resp. loc_cmp.
Say, having two or 3 topmost bits of those 30 for code (0 for REG, 1 for MEM, 2
for VALUE, 3 for anything else) and for each code encode something in the other
bits (e.g. REGNO for REG, 2 bits REG/MEM/VALUE/other for MEM's address than the
rest of bits, saturating VALUE uid for VALUEs, something else for other codes).
Then we'd call rtx_equal_p or loc_cmp only if two values are equal.

Or better find a way how to do less work during dataflow merges.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug rtl-optimization/43632] [4.5 Regression] -g option became very slow after r157834

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-04-06 11:21 -------
GCC 4.5.0 is being released.  Deferring to 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.0                       |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632

[Bug rtl-optimization/43632] [4.5/4.6 Regression] -g option became very slow after r157834

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-06-04 19:34 -------
After the recent var-tracking.c PR41371 changes this is down to 67 seconds.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43632