public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/58318] New: very slow compilation on x86_64-linux with -O3 and -g
@ 2013-09-05  2:00 su at cs dot ucdavis.edu
  2013-09-05  8:58 ` [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled rguenth at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: su at cs dot ucdavis.edu @ 2013-09-05  2:00 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 58318
           Summary: very slow compilation on x86_64-linux with -O3 and -g
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The following code takes much longer to compile with both -O3 and -g on using
the current gcc trunk on x86_64-linux (in both 32-bit and 64-bit modes). 

4.8 is considerably faster than the trunk, while 4.6 and 4.7 are much slower. 

For reference, I also included the times for clang and icc. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130904 (experimental) [trunk revision 202240] (GCC) 
$
$
$ time gcc-trunk -O3 reduced.c
0.06user 0.00system 0:00.23elapsed 30%CPU (0avgtext+0avgdata 51792maxresident)k
0inputs+32outputs (0major+7258minor)pagefaults 0swaps
$
$
$ time gcc-trunk -O3 -g reduced.c
11.70user 0.68system 0:18.93elapsed 65%CPU (0avgtext+0avgdata
1133520maxresident)k
0inputs+64outputs (0major+297028minor)pagefaults 0swaps
$
$
$ time gcc-4.8 -O3 -g reduced.c
0.89user 0.12system 0:01.54elapsed 65%CPU (0avgtext+0avgdata
487552maxresident)k
0inputs+64outputs (0major+50913minor)pagefaults 0swaps
$
$
$ time gcc-4.7 -O3 -g reduced.c
84.09user 0.10system 1:57.58elapsed 71%CPU (0avgtext+0avgdata
580944maxresident)k
0inputs+64outputs (0major+41887minor)pagefaults 0swaps
$
$
$ time gcc-4.6 -O3 -g reduced.c
83.83user 0.16system 2:00.92elapsed 69%CPU (0avgtext+0avgdata
558864maxresident)k
0inputs+64outputs (0major+40733minor)pagefaults 0swaps
$
$
$ time clang-trunk -O3 -g reduced.c
0.02user 0.00system 0:00.09elapsed 34%CPU (0avgtext+0avgdata 52064maxresident)k
0inputs+40outputs (0major+6282minor)pagefaults 0swaps
$
$
$ time icc -O3 -g reduced.c
0.26user 2.39system 0:04.07elapsed 65%CPU (0avgtext+0avgdata 84000maxresident)k
1424inputs+184outputs (14major+16463minor)pagefaults 0swaps
$ 
$


-------------------------------------


int a, b, c, d;

int *foo (int *r, short s, short t)
{
  return &c;
}

short bar (int p)
{
  int t = 0;

  for (a = 0; a < 8; a++)
    for (b = 0; b < 8; b++)
      for (p = 0; p < 8; p++)
    for (d = 0; d < 8; d++)
      foo (&t, p, d);

  bar (0);

  return 0;
}

int main ()
{
  return 0;
}


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled
  2013-09-05  2:00 [Bug tree-optimization/58318] New: very slow compilation on x86_64-linux with -O3 and -g su at cs dot ucdavis.edu
@ 2013-09-05  8:58 ` rguenth at gcc dot gnu.org
  2013-09-05 15:23 ` su at cs dot ucdavis.edu
  2013-09-19 19:54 ` su at cs dot ucdavis.edu
  2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-09-05  8:58 UTC (permalink / raw)
  To: gcc-bugs

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |compile-time-hog
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-05
            Version|unknown                     |4.9.0
            Summary|very slow compilation on    |very slow compilation on
                   |x86_64-linux with -O3 and   |x86_64-linux with -O3 and
                   |-g                          |-g and checking enabled
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  We completely unroll the loop nest in bar () after inlining foo ().
In the -g case we retain a ton of DEBUG_STMTs - 577185 - in a single basic
block.  So walking all of them causes the slowdown, the walking done by
the verifiers - did you compare trunk with --enable-checking=release?  I can
see the same stmts with using GCC 4.8.

A quick check with a non-bootstrapped cc1 but release checking makes the
slowdown go away.

Still, eventually the checkers may need some speed related TLC.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled
  2013-09-05  2:00 [Bug tree-optimization/58318] New: very slow compilation on x86_64-linux with -O3 and -g su at cs dot ucdavis.edu
  2013-09-05  8:58 ` [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled rguenth at gcc dot gnu.org
@ 2013-09-05 15:23 ` su at cs dot ucdavis.edu
  2013-09-19 19:54 ` su at cs dot ucdavis.edu
  2 siblings, 0 replies; 4+ messages in thread
From: su at cs dot ucdavis.edu @ 2013-09-05 15:23 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Zhendong Su <su at cs dot ucdavis.edu> ---
> did you compare trunk with --enable-checking=release?  

Richard, you are right. Below is my 4.8 config: 

$ gcc-4.8 -v
Using built-in specs.
COLLECT_GCC=gcc-4.8
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking
--with-gmp=/usr/local/gcc-4.8 --with-mpfr=/usr/local/gcc-4.8
--with-mpc=/usr/local/gcc-4.8 --with-cloog=/usr/local/gcc-4.8
--prefix=/usr/local/gcc-4.8
Thread model: posix
gcc version 4.8.1 (GCC) 
$


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled
  2013-09-05  2:00 [Bug tree-optimization/58318] New: very slow compilation on x86_64-linux with -O3 and -g su at cs dot ucdavis.edu
  2013-09-05  8:58 ` [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled rguenth at gcc dot gnu.org
  2013-09-05 15:23 ` su at cs dot ucdavis.edu
@ 2013-09-19 19:54 ` su at cs dot ucdavis.edu
  2 siblings, 0 replies; 4+ messages in thread
From: su at cs dot ucdavis.edu @ 2013-09-19 19:54 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Zhendong Su <su at cs dot ucdavis.edu> ---
> A quick check with a non-bootstrapped cc1 but release checking makes the
> slowdown go away.

Richard, there is related testcase that I have just reported (58479). It
manifests also under release checking. Thanks.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-09-19 19:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-05  2:00 [Bug tree-optimization/58318] New: very slow compilation on x86_64-linux with -O3 and -g su at cs dot ucdavis.edu
2013-09-05  8:58 ` [Bug tree-optimization/58318] very slow compilation on x86_64-linux with -O3 and -g and checking enabled rguenth at gcc dot gnu.org
2013-09-05 15:23 ` su at cs dot ucdavis.edu
2013-09-19 19:54 ` su at cs dot ucdavis.edu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).