Bug 36439 - [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
Summary: [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.3.1
: P2 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
: 39210 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-06-05 10:59 UTC by Debian GCC Maintainers
Modified: 2011-06-27 11:27 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.2.4, 4.4.0
Known to fail: 4.3.2
Last reconfirmed: 2008-11-02 12:48:47


Attachments
testcase (153.81 KB, application/octet-stream)
2008-06-05 11:37 UTC, Richard Biener
Details
smaller testcase (21.60 KB, text/plain)
2008-06-07 14:39 UTC, Ryan Hill
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2008-06-05 10:59:23 UTC
[forwarded from http://bugs.debian.org/484569]

seen with 4.3.1 20080523, works with 4.2.4. Replacing -O2 with -O1 lets the build succeed.

  Matthias

g++ -Wall -g -O2 -save-temps -pthread greycstoration4gimp.ii
timed out after 150min on various buildds.
Comment 1 Richard Biener 2008-06-05 11:24:02 UTC
In function cimg_library::CImg<T>& cimg_library::CImg<T>::blur_patch(unsigned int, float, float, unsigned int, bool), which contains some number of loops from
macro expansion stuff.  -fno-tree-pre "fixes" it.  phi-translation is dog slow.
Comment 2 Richard Biener 2008-06-05 11:37:23 UTC
Created attachment 15722 [details]
testcase
Comment 3 Richard Biener 2008-06-06 14:59:37 UTC
4.3.1 is being released, adjusting target milestone.
Comment 4 Ryan Hill 2008-06-07 14:39:39 UTC
Created attachment 15728 [details]
smaller testcase
Comment 5 Joseph S. Myers 2008-08-27 22:04:24 UTC
4.3.2 is released, changing milestones to 4.3.3.
Comment 6 Richard Biener 2008-11-02 12:33:16 UTC
It seems to work on the trunk now.  I'm trying to reduce it on the branch.
Comment 7 Richard Biener 2008-11-02 12:48:47 UTC
We take a long time in compute_antic in the loop

      for (i = 0; i < last_basic_block - NUM_FIXED_BLOCKS; i++)
        {
          if (TEST_BIT (changed_blocks, postorder[i]))
            {
              basic_block block = BASIC_BLOCK (postorder[i]);
              changed |= compute_antic_aux (block,
                                            TEST_BIT (has_abnormal_preds,
                                                      block->index));
            }
        }

(gdb) print cfun->cfg->x_last_basic_block
$22 = 3220

and some invocations of compute_antic_aux take a really long time during
phi_translate_set because the to translate set is really large (it has
in one case 11885 elements).

probably not much to do here ...
Comment 8 Richard Biener 2009-01-24 10:20:26 UTC
GCC 4.3.3 is being released, adjusting target milestone.
Comment 9 Steven Bosscher 2009-02-19 19:57:38 UTC
*** Bug 39210 has been marked as a duplicate of this bug. ***
Comment 10 Richard Biener 2009-08-04 12:29:11 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 11 kurt 2010-03-19 00:34:59 UTC
(In reply to comment #10)
> GCC 4.3.4 is being released, adjusting target milestone.

Very non-scientific benchmark:
Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make -j8 and compile flags: 
-O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops -ftree-vectorize
Times (in seconds, user, elapsed):
4.3.5:             1263u, 377e
 w/ -fno-tree-pre:  755u, 202e
4.4.4:             1022u, 311e
 w/ -fno-tree-pre:  996u, 284e
4.5.0:             2325u, 615e
 w/ -fno-tree-pre: 1974u, 543e

Note that this is in contrast to earlier observations that 4.4/4.5 did do much better than 4.3. Don't know whether that's caused by changed gmic code or whether we have regressed in 4.5. Let me know if you want me to pick one file that takes particularly long to compile and investigate further.
Comment 12 Andrew Pinski 2010-03-19 00:36:40 UTC
Well for 4.5, make sure you configured with --enable-checking=release; otherwise it is not a fair comparison.
Comment 13 kurt 2010-03-19 08:03:17 UTC
> Well for 4.5, make sure you configured with --enable-checking=release;
> otherwise it is not a fair comparison.

Did not change anything unfortunately :-(
(I have enabled --enable-lto in case this matters, though I have not used any compile time flag to make use of it ...)
Comment 14 rguenther@suse.de 2010-03-19 10:09:13 UTC
Subject: Re:  [4.3 Regression] very long
 compile-time in PRE building gimp-plugin-registry

On Fri, 19 Mar 2010, kurt at garloff dot de wrote:

> ------- Comment #11 from kurt at garloff dot de  2010-03-19 00:34 -------
> (In reply to comment #10)
> > GCC 4.3.4 is being released, adjusting target milestone.
> 
> Very non-scientific benchmark:
> Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make
> -j8 and compile flags: 
> -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops
> -ftree-vectorize
> Times (in seconds, user, elapsed):
> 4.3.5:             1263u, 377e
>  w/ -fno-tree-pre:  755u, 202e
> 4.4.4:             1022u, 311e
>  w/ -fno-tree-pre:  996u, 284e
> 4.5.0:             2325u, 615e
>  w/ -fno-tree-pre: 1974u, 543e
> 
> Note that this is in contrast to earlier observations that 4.4/4.5 did do much
> better than 4.3. Don't know whether that's caused by changed gmic code or
> whether we have regressed in 4.5. Let me know if you want me to pick one file
> that takes particularly long to compile and investigate further.

This bug was about PRE causing compile-time issues at -O2 which is
what was investigated and fixed for the testcases attached to this PR.

I see, for -O2 and the CImg.C testcase (just using openSUSE packages
from devel:gcc):

4.3.4 (r152973): stopped after 4min
4.4.2 (r155966): 68s
4.5.0 (r157384): 74s

also see PR43415 for a similar problem where I am about to commit a
patch.

If you can provide a testcase for plain -O3 [-ffast-math -funroll-loops] 
being slow it would be appropriate to open a new bugreport for it.

Thanks,
Richard.
Comment 15 Richard Biener 2010-03-19 10:15:37 UTC
(In reply to comment #14)
> Subject: Re:  [4.3 Regression] very long
>  compile-time in PRE building gimp-plugin-registry
> 
> On Fri, 19 Mar 2010, kurt at garloff dot de wrote:
> 
> > ------- Comment #11 from kurt at garloff dot de  2010-03-19 00:34 -------
> > (In reply to comment #10)
> > > GCC 4.3.4 is being released, adjusting target milestone.
> > 
> > Very non-scientific benchmark:
> > Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make
> > -j8 and compile flags: 
> > -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops
> > -ftree-vectorize
> > Times (in seconds, user, elapsed):
> > 4.3.5:             1263u, 377e
> >  w/ -fno-tree-pre:  755u, 202e
> > 4.4.4:             1022u, 311e
> >  w/ -fno-tree-pre:  996u, 284e
> > 4.5.0:             2325u, 615e
> >  w/ -fno-tree-pre: 1974u, 543e
> > 
> > Note that this is in contrast to earlier observations that 4.4/4.5 did do much
> > better than 4.3. Don't know whether that's caused by changed gmic code or
> > whether we have regressed in 4.5. Let me know if you want me to pick one file
> > that takes particularly long to compile and investigate further.
> 
> This bug was about PRE causing compile-time issues at -O2 which is
> what was investigated and fixed for the testcases attached to this PR.
> 
> I see, for -O2 and the CImg.C testcase (just using openSUSE packages
> from devel:gcc):
> 
> 4.3.4 (r152973): stopped after 4min
> 4.4.2 (r155966): 68s
> 4.5.0 (r157384): 74s
> 
> also see PR43415 for a similar problem where I am about to commit a
> patch.
> 
> If you can provide a testcase for plain -O3 [-ffast-math -funroll-loops] 
> being slow it would be appropriate to open a new bugreport for it.

Oh, and btw check if you build with debuginfo enabled.  With GCC 4.5 we
can spend quite some extra time producing "good" debug information.
Comment 16 Richard Biener 2010-05-22 18:12:23 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 17 Richard Biener 2011-06-27 11:27:27 UTC
Fixed for 4.4.0.