This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)
- To: pfeifer at dbai dot tuwien dot ac dot at (Gerald Pfeifer)
- Subject: Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Fri, 20 Jul 2001 14:19:23 -0700 (PDT)
- Cc: mark at codesourcery dot com (Mark Mitchell), gcc at gcc dot gnu dot org
> On Wed, 18 Jul 2001, Mark Mitchell wrote:
> > I know we have already made some pretty significant bug-fixes, so I'm
> > confident that the 3.0.1 release will be useful to current 3.0 users.
> > It would be nice to address some of the lingering issues relative to
> > GCC 2.95 that are preventing people from upgrading.
Gerald writes:
> Well, here I have to step up again, I'm afraid. If you look at
> http://gcc.gnu.org/ml/gcc/2001-07/msg01376.html
> you'll see that C++ projects heavily relying on STL apparently
> simply cannot use GCC 3.0.
Rather, probably don't want to use 3.0 yet.
> GCC 2.95 GCC 3.0
> Compile time Binary size Compile time Binary Size
> -O0 6:19 3915128 8:20 4159780
> -O1 4:20 4203480 11:40 4829732
> -O2 5:56 4209368 14:09 4862532
> -O3 5:47 4221464 32:04 6166052
This makes it clear that -O3 is unusable at the moment, but that's no surprise;
better to let the user rather than the compiler decide which functions
to inline. That leaves us with (for -O2) 2.38 times the compile time,
and 16% larger code.
> This is not (only) an inlining problem it seems?
I suggest making like Brad Lucier and posting profiling data, to help
track down where the extra time is being spent.
> And, as shown by the table in my original message, the generated code
> is also significantly slower, probably because of the ADDRESSOF issue
> which still has not been resolved yet, AFAIK?
Again, to help, the developers are going to need to see examples of where
the pessimization is showing up, ideally important loops that are yielding
worse code.