GCC 3.0.1 Status Report

GCC 3.0.1 Status Report

[Mark Mitchell]

We are nearing the pre-3.0.1 freeze.

In particular, after midnight GMT - 0800 on July 21st, non-documentation 
check-ins on the branch will require my approval.  I will make a release
candidate at that time, for the planned August 1st release.

If things don't make it into this bug-fix release, they can always go
into GCC 3.0.2, due in October.

However, if there are regressions on the 3.0 branch, relative to GCC
3.0, then we should know about them.  If you are aware of such
issues, make sure they are in GNATS, and make me aware by emailing
me directly, including the PR numbers.

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.

If you are working on fixes that you would like to see in GCC 3.0.1,
now is the time to finish them up.  This is partly a reminder to myself; 
I've been working on the new C++ parser, and that's meant I haven't fixed 
some bugs in GNATS that I should get going on right away.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.0.1 Status Report

[Joseph S. Myers]

On Wed, 18 Jul 2001, Mark Mitchell wrote:

> check-ins on the branch will require my approval.  I will make a release
> candidate at that time, for the planned August 1st release.

This release candidate should probably include diffs from 3.0, to test the 
diff production mechanisms (gcc_release -p).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCC 3.0.1 Status Report

[Nathan Sidwell]

Mark Mitchell wrote:
> 
> We are nearing the pre-3.0.1 freeze.
As we all know, there are still problems with ctor vtables and
polymorphic virtual base class initialization. I have had a look
at some of those, but failed to make headway due to lack of time and
a twisty maze of base class accessor functions. Rather than
battle against the impending deadline to fix these (as we tried
for 3.0), I'm not even going to try. Racing for the deadline
will most surely miss something.

I aim to fix these in 3.1, but first I'm going to remove the
old-abi cruft which is confusing the issue right now.

I have assigned gnats bugs relating to this stuff to me. If anyone
wishes to take them up for 3.0.1, let me know.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

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.

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.

                   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 is not (only) an inlining problem it seems?

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?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Nathan Sidwell]

Gerald Pfeifer wrote:

>                    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 is not (only) an inlining problem it seems?
Do you have the .ii file sizes to compare? Is there a correlation with
compile time?

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Mark Mitchell]

> 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.

An extreme statement, but, that aside, as you know people are working
on fixes.  The point is that 3.0.1 is better than 3.0; that is good.
Ideally, it would be better, but the point is to make consistent
progress.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> 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.
> 
> 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.
> 
>                    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 is not (only) an inlining problem it seems?

We *still* haven't changed the inlining default.

> 
> 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?


> 
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
> 
> 
> 
> 
> 
> 

-- 
"I bought one of those little glass ball things with the snow in
it.  You know, you turn it upside down then you turn it back and
it starts to snow.  I bought one, except this has a snow plow
that does it in rows.
"-Steven Wright

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

> 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.

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

Gerald:
> > 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.

Mark:
> An extreme statement, but, that aside, as you know people are working
> on fixes.  The point is that 3.0.1 is better than 3.0; that is good.
> Ideally, it would be better, but the point is to make consistent
> progress.

To make more progress and make 3.0.2 usable, we may need to broaden the
acceptance criteria beyond just fixing regressions.  If we can find
fairly simple patches that improve performance, they should be considered
for inclusion.

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Mark Mitchell]

> To make more progress and make 3.0.2 usable, we may need to broaden the
> acceptance criteria beyond just fixing regressions.  If we can find
> fairly simple patches that improve performance, they should be considered
> for inclusion.

I 100% agree; in fact, this *is* a regression and a fix is most welcome.

I expect Daniel's change to be sufficient to moderate the damage; I
expect that we will now see somewhat worse compile-times and possibly
somewhat worse execution-times, relative to GCC 2.95.x, instead of
horrendously worse compile-times.  So, I hope that this will make
even 3.0.1 more useful.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Loren James Rittle]

In article < 3B587049.19D267B@codesourcery.com > you write:
>Gerald Pfeifer wrote:

>>                    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 is not (only) an inlining problem it seems?

From what I understand, the above data is for the build of an entire
program and not just one source translation.  Is that correct, Gerald?

> Do you have the .ii file sizes to compare? Is there a correlation with
> compile time?

[This issue was studied a bit before the 3.0 release, see
 http://gcc.gnu.org/ml/libstdc++/2001-02/msg00365.html and followup.]

Here is some concrete data to answer your questions.  First we study
the speed of header declaration processing.  (BTW, I believe that this
analysis is being quite generous to 3.0 since it deemphasizes the
massive growth in some commonly used standard headers.)

Start with libstdc++-v3/testsuite/17_intro/headers.cc.  Remove all
headers which did not exist in 2.95.  Remove <bitset> since the 2.95
preprocessed source related to that header will not compile under 3.0.
Create 295.ii and 30.ii as follows:

g++-2.95.3 -E headers.cc >295.ii  # 643817 bytes
g++-3.0 -E headers.cc >30.ii  # 1020257 bytes

Run each ii file against each compiler (thus size shouldn't matter):

``g++-2.95.3 -c -O[0-3] 295.ii'' requires about 2.7 seconds on my
platform regardless of optimization level (as expected).  FYI, adding
-fhonor-std or -fnew-abi does not appear to affect speed of
declaration processing.

``g++-3.0 -c -O[0-3] 295.ii'' requires about 4.3 seconds on my
platform regardless of optimization level (as expected).

``g++-2.95.3 -c -O[0-3] 30.ii'' does not compile.  Adding the obvious
extra switches (-fhonor-std -fnew-abi) doesn't help.

``g++-3.0 -c -O[0-3] 30.ii'' requires about 5.7 seconds on my platform
regardless of optimization level (as expected).

The above data was taken from i386-unknown-freebsd4.3.  Here is for
sparc-sun-solaris2.7:

g++-2.95.3 -E headers.cc >295.ii  # 662909 bytes
g++-3.0 -E headers.cc >30.ii  # 1055701 bytes

Times (in same order as above): 4.1s, 7.0s, NA, 9.6s

Times for alpha-unknown-freebsd4.2: 4.2s, 9.1s, NA, 11.7s

I conclude that in terms of header declaration processing, g++ 3.0 is
slower than g++ 2.95.3 by a factor of 1.6 (4.3/2.7) to 2.1 (9.1/4.2).
When one considers that the standard headers are now bigger (much
bigger, in some common cases), it appears slower by a larger factor
when comparing compilation speed of user-provided code.

Next, we would study the code generation processing at various
optimization levels.  Gerald's data displays the issue of code
generation speed for real application code, and I have no better
example to post off-hand.  I am the only one that finds it odd that
-O0 takes longer to compile than -O1, -O2 and -O3 under 2.95.3?

Regards,
Loren

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

Mark writes:

> I expect Daniel's change to be sufficient to moderate the damage; I
> expect that we will now see somewhat worse compile-times and possibly
> somewhat worse execution-times, relative to GCC 2.95.x, instead of
> horrendously worse compile-times.  So, I hope that this will make
> even 3.0.1 more useful.

Gerald, could you test Daniel's change and see if it helps on your code?

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

On Fri, 20 Jul 2001, Nathan Sidwell wrote:
>>                    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
> Do you have the .ii file sizes to compare? Is there a correlation with
> compile time?

Not that strongly, I'd say:

  % wc -l 2.95/* | grep total
  472019 total
  % wc -l 3.0/* | grep total
  575530 total

That is, the 17 preprocessed source files become larger, but not that
much (compared to compile time).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

On Fri, 20 Jul 2001, Loren James Rittle wrote:
> From what I understand, the above data is for the build of an entire
> program and not just one source translation.  Is that correct, Gerald?

Yes.

> [This issue was studied a bit before the 3.0 release, see
>  http://gcc.gnu.org/ml/libstdc++/2001-02/msg00365.html and followup.]
> [...]
> I conclude that in terms of header declaration processing, g++ 3.0 is
> slower than g++ 2.95.3 by a factor of 1.6 (4.3/2.7) to 2.1 (9.1/4.2).
> When one considers that the standard headers are now bigger (much
> bigger, in some common cases), it appears slower by a larger factor
> when comparing compilation speed of user-provided code.

Very interesting; thanks!

> I am the only one that finds it odd that -O0 takes longer to compile
> than -O1, -O2 and -O3 under 2.95.3?

Having rerun the tests in the meantime to analyse this particular strange
data point, it seems that the timing for -O0 using GCC 2.95.3 indeed must
have been skewed by some external influences; I now obtained timings also
for -O0 along the lines you'd expect.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

On Fri, 20 Jul 2001, Mark Mitchell wrote:
>> you'll see that C++ projects heavily relying on STL apparently
>> simply cannot use GCC 3.0.
> An extreme statement, but, that aside, as you know people are working
> on fixes.

Yes, and I really appreciate that.

And I especially hope that our new development model will make prevention
of such problems easier by providing a much more stable head branch that
we can benchmark against regularily.

On Fri, 20 Jul 2001, Joe Buck wrote:
> Gerald, could you test Daniel's change and see if it helps on your code?

Of course! Here we go:

          GCC 2.95.3           GCC 3.0          GCC 3.0.1-pre
         Time    Size        Time   Size         Time   Size
  -O0    6:19    3915128     8:20   4159780      8:00   4159588
  -O1    4:20    4203480    11:40   4829732      7:09   3997668
  -O2    5:56    4209368    14:09   4862532      7:53   3987556
  -O3    5:47    4221464    32:04   6166052      7:54   3987140

The huge compile-time regression is gone, though we are still noticably
slower than GCC 2.95; and binary size is even better than it used to be.

That is, there is still work to do to make the compiler faster, but it's
*much* nicer now.

About run-time performance, I'll report later when tests have been
finished.

Gerald
-- 

Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

I wrote:
> > Gerald, could you test Daniel's change and see if it helps on your code?
> 
> Of course! Here we go:
> 
>           GCC 2.95.3           GCC 3.0          GCC 3.0.1-pre
>          Time    Size        Time   Size         Time   Size
>   -O0    6:19    3915128     8:20   4159780      8:00   4159588
>   -O1    4:20    4203480    11:40   4829732      7:09   3997668
>   -O2    5:56    4209368    14:09   4862532      7:53   3987556
>   -O3    5:47    4221464    32:04   6166052      7:54   3987140
> 
> The huge compile-time regression is gone, though we are still noticably
> slower than GCC 2.95; and binary size is even better than it used to be.

Elsewhere Gerald posted the size of the preprocessed code:

>  % wc -l 2.95/* | grep total
>  472019 total
>  % wc -l 3.0/* | grep total
>  575530 total

So the preprocessed code is 21% larger, and for -O0 it compiles 26%
slower.  After normalization for lines of preprocessed code, 3.0.1-pre is
only 3.8% slower on a per-line basis than 2.95.3 with optimization off
(normal mode for the typical compile/debug/fix cycle).

Smaller binaries too ... maybe the compiler's going to be OK after all. :-)

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> On Fri, 20 Jul 2001, Mark Mitchell wrote:
>>> you'll see that C++ projects heavily relying on STL apparently
>>> simply cannot use GCC 3.0.
>> An extreme statement, but, that aside, as you know people are working
>> on fixes.
> 
> Yes, and I really appreciate that.
> 
> And I especially hope that our new development model will make prevention
> of such problems easier by providing a much more stable head branch that
> we can benchmark against regularily.
> 
> On Fri, 20 Jul 2001, Joe Buck wrote:
>> Gerald, could you test Daniel's change and see if it helps on your code?
> 
> Of course! Here we go:
> 
>           GCC 2.95.3           GCC 3.0          GCC 3.0.1-pre
>          Time    Size        Time   Size         Time   Size
>   -O0    6:19    3915128     8:20   4159780      8:00   4159588
>   -O1    4:20    4203480    11:40   4829732      7:09   3997668
>   -O2    5:56    4209368    14:09   4862532      7:53   3987556
>   -O3    5:47    4221464    32:04   6166052      7:54   3987140
> 
> The huge compile-time regression is gone, though we are still noticably
> slower than GCC 2.95; and binary size is even better than it used to be.
> 
> That is, there is still work to do to make the compiler faster, but it's
> *much* nicer now.
> 

Tree based optimizations should help on making it faster, as well as
the new parser.
After that our new bottlenecks *should* be (and if they aren't,
we should be able to  make it so they are):

1. Scheduling.
2. Register Allocation.
3. Instruction combiner.


With the store motion changes, we can turn off CSE follow-jumps and
skip-blocks. I tested it, and got the same performance with those off,
and with them on.  Without the store motion fixes i submitted, and
aren't reviewed yet, we'll get slower code with those off.

With follow-jumps and skip-blocks on, CSE takes longer than GCSE with
store motion fixed.
This is kinda silly, since it's a local algorithm.

If GCSE still takes too long (It seems to be a constant 12% of the
time, when i start throwing large enough stuff that it's time isn't
lost in the noise), we can convert to SSA based PRE.
Past that, e very other compiler i know of started using region based compiling
(HP's ELCOR, SGI Pro64, SGI's mipspro, Intel's compilers,
IBM's compilers, etc) in order to cut down the compile time while speeding
up the code.

From what i understand, it works quite well.

Some tried flat interprocedural analysis, but it was too slow.  Some
still do it for alias analysis, however.

--Dan



> About run-time performance, I'll report later when tests have been
> finished.
> 
> Gerald
> -- 
> 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

-- 
"I bought my brother some gift-wrap for Christmas.  I took it to
the Gift Wrap Department and told them to wrap it, but in a
different print so he would know when to stop unwrapping.
"-Steven Wright

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:

> 
> Next, we would study the code generation processing at various
> optimization levels.  Gerald's data displays the issue of code
> generation speed for real application code, and I have no better
> example to post off-hand.  I am the only one that finds it odd that
> -O0 takes longer to compile than -O1, -O2 and -O3 under 2.95.3?

It shouldn't take longer to compile at -O1,-O2,-O3 than -O0, because
the slow parts of the compiler don't have as much code to wade
through.

> 
> Regards,
> Loren

-- 
"I wrote a few children's books...  Not on purpose.
"-Steven Wright

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5372 bytes --]

On Mon, 23 Jul 2001, Joe Buck wrote:
> So the preprocessed code is 21% larger, and for -O0 it compiles 26%
> slower.  After normalization for lines of preprocessed code, 3.0.1-pre is
> only 3.8% slower on a per-line basis than 2.95.3 with optimization off
> (normal mode for the typical compile/debug/fix cycle).

Yes, but as a user you'll still see 26% slowdown, for those 21% increase
of preprocessed source come from libstdc++.

> Smaller binaries too ... maybe the compiler's going to be OK after all. :-)

No. Not yet. :-(  Performance benchmarks are *detrimental*. Desastrous. :-(

Gerald

                     |2.95 -O2|2.95 -O3| 3.0 -O2| 3.0 -O3|3.0.1-O2|3.0.1-O3|
---------------------+-----------------------------------------------------+
      STRATCOMP1-ALL |   8.26 |   8.07 |  94.42 |  94.50 | 107.90 | 103.03 |
   STRATCOMP-770.2-Q |   1.45 |   1.30 |   1.47 |   1.43 |   3.77 |   3.73 |
               2QBF1 |  25.45 |  25.70 |  35.17 |  40.98 |  74.73 |  77.54 |
          PRIMEIMPL2 |  18.93 |  19.04 |  24.20 |  28.00 | 112.64 | 116.13 |
            ANCESTOR |  13.98 |  12.97 |  12.53 |  11.54 |  37.24 |  37.18 |
       3COL-SIMPLEX1 |  13.88 |  11.78 |  12.26 |  11.60 |  33.27 |  33.03 |
        3COL-LADDER1 |  58.59 |  56.47 |  70.89 |  79.84 | 169.75 | 173.26 |
      3COL-N-LADDER1 |  22.60 |  24.39 |  25.49 |  28.32 | 111.93 | 112.95 |
        3COL-RANDOM1 |  18.61 |  19.08 |  23.25 |  26.07 |  92.60 |  96.46 |
          HP-RANDOM1 |  15.78 |  14.55 |  15.72 |  15.19 |  42.04 |  43.02 |
       HAMCYCLE-FREE |   2.61 |   2.11 |   2.92 |   2.49 |   9.97 |  10.32 |
             DECOMP2 |  34.90 |  33.28 |  29.63 |  34.50 | 113.99 | 117.11 |
        BW-P4-Esra-a | 110.08 | 108.56 | 116.19 | 123.85 | 345.82 | 359.78 |
        BW-P5-nopush |   8.69 |   8.56 |   8.99 |   9.56 |  27.41 |  28.53 |
       BW-P5-pushbin |   8.04 |   7.89 |   8.23 |   8.89 |  28.43 |  29.43 |
     BW-P5-nopushbin |   2.89 |   2.76 |   2.83 |   3.03 |   9.67 |  10.00 |
              3SAT-1 |  60.92 |  60.80 |  75.32 |  85.46 | 344.55 | 355.46 |
   3SAT-1-CONSTRAINT |  32.45 |  31.80 |  39.17 |  47.33 | 180.67 | 192.74 |
        HANOI-Towers |   6.78 |   6.29 |   5.82 |   6.64 |  21.53 |  19.00 |
              RAMSEY |  15.74 |  13.95 |  16.78 |  15.08 |  44.17 |  44.33 |
             CRISTAL |  16.49 |  14.76 |  16.50 |  15.41 |  42.85 |  42.53 |
             HANOI-K |  60.29 |  58.87 |  72.22 |  78.86 | 299.82 | 316.15 |
           21-QUEENS |  18.32 |  18.55 |  22.18 |  24.31 |  88.71 |  93.89 |
   MSTDir[V=13,A=40] |  43.67 |  42.22 |  35.77 |  35.58 | 101.60 | 107.67 |
   MSTDir[V=15,A=40] |  44.54 |  42.70 |  35.88 |  35.18 | 100.76 | 106.31 |
 MSTUndir[V=13,A=40] |  22.61 |  21.43 |  19.30 |  18.79 |  60.34 |  64.53 |
 MSTUndir[V=15,A=40] | 368.26 | 352.57 | 313.58 | 304.77 | 942.22 | 997.93 |
         TIMETABLING |  25.94 |  24.42 |  24.76 |  24.95 |  76.62 |  76.69 |
---------------------+-----------------------------------------------------+

STRATCOMP1-ALL:
STRATCOMP, random instance, |companies| = 60, |products| = 180,
all sets

STRATCOMP-770.2-Q:
STRATCOMP, random instance, |companies| = |products| = 770,
first model, with query

2QBF1:
2QBF, 1000 all-quantified, 20 existentially-quantified variables
10000 clauses, 5CNF

PRIMEIMPL2:
Prime Implicants with 180 variables and 774 clauses (all models [246])

ANCESTOR:
Double ancestor board of size 14 (only grounding)

3COL-SIMPLEX1:
3COL simplex graph, |edges| = 1980, |nodes| = 1035, one model

3COL-LADDER1:
3COL ladder graph, |edges| = 2998, |nodes| = 2000, one model

3COL-N-LADDER1:
3COL, propositional Niemelä style
ladder graph, |edges| = 2998, |nodes| = 2000, one model

3COL-RANDOM1:
3COL random graph, |edges| = 1100, |nodes| = 500, one model

HP-RANDOM1:
Hamiltonian Path on a random graph, |edges| = 700, |nodes| = 85, one model
generated with Stanford Graph Base random_graph(85,700,0,0,0,0,0,1,1,33)
undirected graph, represented as a directed one

HAMCYCLE-FREE:
Hamiltonian Cycle with a free guess.
n = 60, one model

DECOMP2:
query decomposition (k=3), one model

BW-P4-Esra-a:
blocksworld problem P4 with Esra's bw_domain_a program

BW-P5-nopush:
blocksworld problem P5 with Axel's C-translation without push

BW-P5-pushbin:
blocksworld problem P5 with Axel's pushed and binarised C-translation

BW-P5-nopushbin:
blocksworld problem P5 with Axel's binarised C-translation without push

3SAT-1:
3SAT with 280 variables and 1204 clauses, randomly generated, one model

3SAT-1-CONSTRAINT:
3SAT with 280 variables and 1204 clauses, randomly generated, one model, constraint encoding

HANOI-Towers:
"Towers of Hanoi" with 3 stacks, 4 disks, and 15 steps.

RAMSEY:
"Ramsey(3,6) != 17"

CRISTAL:
"Deductive database use as done by Christoph Koch in CERN"

HANOI-K:
"Towers of Hanoi" in K with 3 stacks, 4 disks, and 15 steps.

21-QUEENS:
"N-Queens with 21 queens"

MSTDir[V=13,A=40]:
min spanning tree [prim], directed graph with 13 vertices and 40 arcs

MSTDir[V=15,A=40]:
min spanning tree [prim], directed graph with 15 vertices and 40 arcs

MSTUndir[V=13,A=40]:
min spanning tree [prim], undirected graph with 13 vertices and 40 arcs

MSTUndir[V=15,A=40]:
min spanning tree [prim], undirected graph with 15 vertices and 40 arcs

TIMETABLING:
A timetable problem of the first year of the faculty of Science
of University of Calabria for 1 class, one model

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Bernd Schmidt]

>
> With follow-jumps and skip-blocks on, CSE takes longer than GCSE with
> store motion fixed.
> This is kinda silly, since it's a local algorithm.

We do have a fix for cse's time behavior.  Vlad Makarov submitted a patch
for this about two years or so ago.


Bernd

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[law]

  In message < 877kwzearp.fsf@cgsoftware.com >you write:
  > Past that, e very other compiler i know of started using region based compi
  > ling
  > (HP's ELCOR, SGI Pro64, SGI's mipspro, Intel's compilers,
  > IBM's compilers, etc) in order to cut down the compile time while speeding
  > up the code.
I know that SGI's compiler doesn't actually do region stuff.  They ran into
a rats nest of problems with the actual implementation.

jeff

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

--On Monday, July 23, 2001 1:53 PM -0600 law@redhat.com wrote:

>   In message < 877kwzearp.fsf@cgsoftware.com >you write:
>   > Past that, e very other compiler i know of started using region based
> compi   > ling
>   > (HP's ELCOR, SGI Pro64, SGI's mipspro, Intel's compilers,
>   > IBM's compilers, etc) in order to cut down the compile time while
> speeding   > up the code.
> I know that SGI's compiler doesn't actually do region stuff.  They ran
> into a rats nest of problems with the actual implementation.
>

Err, the source code for pro64 has it in there, and at O2 and O3, it 
certainly goes through that code, and appears to create regions/use them.

Maybe this wasn't done in time for mipspro.

> jeff

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

I wrote:

> > Smaller binaries too ... maybe the compiler's going to be OK after all. :-)
> 
> No. Not yet. :-(  Performance benchmarks are *detrimental*. Desastrous. :-(

To make progress I think we'll need to look at the generated code and
figure out why it is so bad.  By far the worst result seems to be for
STRATCOMP1-ALL:

>                      |2.95 -O2|2.95 -O3| 3.0 -O2| 3.0 -O3|3.0.1-O2|3.0.1-O3|
> ---------------------+-----------------------------------------------------+
>       STRATCOMP1-ALL |   8.26 |   8.07 |  94.42 |  94.50 | 107.90 | 103.03 |

Can you try to isolate where the bad code is?

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[law]

  In message < 856548000.995904843@[192.168.0.106] >you write:
  > >   In message < 877kwzearp.fsf@cgsoftware.com >you write:
  > >   > Past that, e very other compiler i know of started using region based
  > > compi   > ling
  > >   > (HP's ELCOR, SGI Pro64, SGI's mipspro, Intel's compilers,
  > >   > IBM's compilers, etc) in order to cut down the compile time while
  > > speeding   > up the code.
  > > I know that SGI's compiler doesn't actually do region stuff.  They ran
  > > into a rats nest of problems with the actual implementation.
  > >
  > 
  > Err, the source code for pro64 has it in there, and at O2 and O3, it 
  > certainly goes through that code, and appears to create regions/use them.
Certainly all the code is in there, but it's not being used (actually, I
think their team mentioned one case where it is used, but it was fairly minor).

jeff

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Mark Mitchell]

> No. Not yet. :-(  Performance benchmarks are *detrimental*. Desastrous.
> :-(

Would you try experimenting with `--param max-inline-insns=N' for different
values of N to find where a better compromise is?  (It looks like perhaps
100 was too small.  Daniel also indicated the heuristic used to approximate
instructions from statements wasn't scaled quite right, so 100 isn't really
a literal value here.)

You might have already done this experiment, in which case you could submit
a patch to pick a better value.

Realistically, I think we have to be willing to compromise here; the 3.0.1 
compiler is going to be slower *and* probably generate slower code than 
2.95, which is too bad, but that seems to be where we're at.  If we could
get to 10-25% on both figures that would be better than having one figure
small and the other massive.

Then, we continue working on Nathan/Daniel's stuff and hope to have it
ready for 3.1, or maybe even 3.0.2.

-- Mark

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

On Mon, 23 Jul 2001, Joe Buck wrote:
> Can you try to isolate where the bad code is?

Not really.  This code base is relatively large and the inner loops
are quite complicated (actually not really loops as you'd see in usual
scientific computing code) amounting to several thousand lines of code,
and my day job is very time demanding these days, so I'm afraid I simply
won't have the time anytime soon.

I'm rather sure, though, that g++ is not generating efficient code for
complicated, nested STL and STL-like structures in the presence of
libstdc++-v3 (iterators are now classes instead of pointers).

Has this (known) issue been completely resolved yet?  I forgot the
detailed status of that (keyword ADDRESSOF, for example).

Gerald

PS: Of course, once I have the time, I'll try to do what I can.
PPS: And of course I'm willing to make the code including the performance
tests to anyone, even if I haven't succeeded in making this free software
yet, so I cannot offer it from a web site.
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:


> On Mon, 23 Jul 2001, Joe Buck wrote:
>> Can you try to isolate where the bad code is?
> 
> Not really.  This code base is relatively large and the inner loops
> are quite complicated (actually not really loops as you'd see in usual
> scientific computing code) amounting to several thousand lines of code,
> and my day job is very time demanding these days, so I'm afraid I simply
> won't have the time anytime soon.
> 
> I'm rather sure, though, that g++ is not generating efficient code for
> complicated, nested STL and STL-like structures in the presence of
> libstdc++-v3 (iterators are now classes instead of pointers).

This is probably alias analysis's fault.
Can you *try* the patch i posted to do alias analysis for classes,
just to see if it gets better code (Unless mark is wrong, and its not
more complicated than i thought it was, and i seriously doubt he's
wrong, it might generate invalid code)?
I could also do some more analysis if you could make that particular
test available to me.

--Dan

-- 
"I got into an elevator at work and this man followed in after
me...  I pushed "1" and he just stood there...  I said, "Hi,
where you going?"  He said, "Phoenix."  So I pushed Phoenix.  A
few seconds later the doors opened, two tumbleweeds blew in...
We were in downtown Phoenix.  I looked at him and said, "You
know, you're the kind of guy I want to hang around with."  We
got into his car and drove out to his shack in the desert.  Then
the phone rang.  He said, "You get it."  I picked it up and
said, "Hello?"...  The other side said, "Is this Steven
Wright?"...  I said, "Yes..."  The guy said, "Hi, I'm Mr.
Jones, the student loan director from your bank.  It seems you
have missed your last 17 payments, and the university you
attended said that they received none of the $17,000 we loaned
you.  We would just like to know what happened to the money?"  I
said, "Mr.  Jones, I'll give it to you straight.  I gave all of
the money to my friend Slick, and with it he built a nuclear
weapon...  And I would appreciate it if you never called me
again."
"-Steven Wright

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

> I'm rather sure, though, that g++ is not generating efficient code for
> complicated, nested STL and STL-like structures in the presence of
> libstdc++-v3 (iterators are now classes instead of pointers).

But the classes have one member, so we should still be getting equivalent
code, provided that we get ADDRESSOF working as well as it did in 2.95.x.

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.COM> writes:

| > I'm rather sure, though, that g++ is not generating efficient code for
| > complicated, nested STL and STL-like structures in the presence of
| > libstdc++-v3 (iterators are now classes instead of pointers).
| 
| But the classes have one member, so we should still be getting equivalent
| code, provided that we get ADDRESSOF working as well as it did in 2.95.x.

Now that we have a branch for doing tree-based optimization, what do
you think about trying to implement "scalar replacement of aggregates"
optimization and see how good we can do with STL-like structures?

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

Joe Buck <jbuck@synopsys.COM> writes:

>> I'm rather sure, though, that g++ is not generating efficient code for
>> complicated, nested STL and STL-like structures in the presence of
>> libstdc++-v3 (iterators are now classes instead of pointers).
> 
> But the classes have one member, so we should still be getting equivalent
> code, provided that we get ADDRESSOF working as well as it did in
> 2.95.x.

Not necessarily.
Alias analysis for classes says they can alias anything (It puts them
in set 0).
Alias analysis for pointers doesn't.

This can screw us considerably in these cases, since optimizations on
memory will see they can alias everything, and not touch them (or
anything before them, since we have to kill those too).

The reason i started to come up with a patch in the first place to fix
this is because it's quite visible with store motion fixed. 

--Dan

-- 
"The other day, I was walking my dog around my building...  on
the ledge.  Some people are afraid of heights.  Not me, I'm
afraid of widths.
"-Steven Wright

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

> Joe Buck <jbuck@synopsys.COM> writes:
> 
> | > I'm rather sure, though, that g++ is not generating efficient code for
> | > complicated, nested STL and STL-like structures in the presence of
> | > libstdc++-v3 (iterators are now classes instead of pointers).
> | 
> | But the classes have one member, so we should still be getting equivalent
> | code, provided that we get ADDRESSOF working as well as it did in 2.95.x.
> 
> Now that we have a branch for doing tree-based optimization, what do
> you think about trying to implement "scalar replacement of aggregates"
> optimization and see how good we can do with STL-like structures?

Yes!  This is very important, not just for STL-like structures, but for
proxy objects (e.g. references to bits in a packed bit vector class).

You'll find some good test cases in Boost, particularly the Boost Graph
Library; our current compilers (2.95.x or 3.0.x) do poorly because many
of the iterators and function results are classes with more than one data
member.

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Joe Buck]

> Joe Buck <jbuck@synopsys.COM> writes:
> 
> >> I'm rather sure, though, that g++ is not generating efficient code for
> >> complicated, nested STL and STL-like structures in the presence of
> >> libstdc++-v3 (iterators are now classes instead of pointers).
> > 
> > But the classes have one member, so we should still be getting equivalent
> > code, provided that we get ADDRESSOF working as well as it did in
> > 2.95.x.
> 
> Not necessarily.
> Alias analysis for classes says they can alias anything (It puts them
> in set 0).
> Alias analysis for pointers doesn't.

I'm very skeptical of this reasoning.

We're typically talking about code where, after inlining, we can see
*exactly* what the pointer or reference refers to, because it gets set
exactly once.

For the case where ADDRESSOF works, the class object should stay in a
register, so there's no question of aliasing with something in memory.
The problem is with making a decision to put an object in memory too
early.

The iterator is a class, yes, but it has only one data member, which is
a pointer.  There shouldn't be any impact on the aliasing analysis.

> This can screw us considerably in these cases, since optimizations on
> memory will see they can alias everything, and not touch them (or
> anything before them, since we have to kill those too).
> 
> The reason i started to come up with a patch in the first place to fix
> this is because it's quite visible with store motion fixed. 

Your store motion work cleans up stuff that, in this case, never should
have been generated in the first place.

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| > Joe Buck <jbuck@synopsys.COM> writes:
| > 
| > | > I'm rather sure, though, that g++ is not generating efficient code for
| > | > complicated, nested STL and STL-like structures in the presence of
| > | > libstdc++-v3 (iterators are now classes instead of pointers).
| > | 
| > | But the classes have one member, so we should still be getting equivalent
| > | code, provided that we get ADDRESSOF working as well as it did in 2.95.x.
| > 
| > Now that we have a branch for doing tree-based optimization, what do
| > you think about trying to implement "scalar replacement of aggregates"
| > optimization and see how good we can do with STL-like structures?
| 
| Yes!  This is very important, not just for STL-like structures, but for
| proxy objects (e.g. references to bits in a packed bit vector class).

Yes, I have similar concern with "small" classes like color, point,
vector classes in my personal scientific visualization applications.

| You'll find some good test cases in Boost, particularly the Boost Graph
| Library; our current compilers (2.95.x or 3.0.x) do poorly because many
| of the iterators and function results are classes with more than one data
| member.

Thanks.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Daniel Berlin]

Joe Buck <jbuck@synopsys.com> writes:

>> Joe Buck <jbuck@synopsys.COM> writes:
>> 
>> >> I'm rather sure, though, that g++ is not generating efficient code for
>> >> complicated, nested STL and STL-like structures in the presence of
>> >> libstdc++-v3 (iterators are now classes instead of pointers).
>> > 
>> > But the classes have one member, so we should still be getting equivalent
>> > code, provided that we get ADDRESSOF working as well as it did in
>> > 2.95.x.
>> 
>> Not necessarily.
>> Alias analysis for classes says they can alias anything (It puts them
>> in set 0).
>> Alias analysis for pointers doesn't.
> 
> I'm very skeptical of this reasoning.
> 
> We're typically talking about code where, after inlining, we can see
> *exactly* what the pointer or reference refers to, because it gets set
> exactly once.


> 
> For the case where ADDRESSOF works, the class object should stay in a
> register, so there's no question of aliasing with something in memory.
> The problem is with making a decision to put an object in memory too
> early.
> 
> The iterator is a class, yes, but it has only one data member, which is
> a pointer.  There shouldn't be any impact on the aliasing analysis.

Yes yes, you are correct, i'm just cleaning up the mess something else
makes, in effect.

You (I would, but i'm having fun with new register allocator work,
and callgraph and loop stuff on trees right now. Maybe in a few more
months) should make a go at real scalar replacement of aggregates in
the ast-optimizer branch. 



-- 
"It's a good apartment because they allow pets.  I have a
Shetland pony named Nikkie.  Last summer Nikkie was involved in
a bizarre electrolysis accident.  All her hair was removed
except for her tail.  Now I rent her out to Hare Krishna family
picnics.
"-Steven Wright

Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report)

[Gerald Pfeifer]

On Tue, 24 Jul 2001, Mark Mitchell wrote:
> Would you try experimenting with `--param max-inline-insns=N' for different
> values of N to find where a better compromise is?

Yes, I've been working on this now.  To be honest, I don't have time to
do this, but I'll try to have something in time for 3.0.1 -- somehow.

> Realistically, I think we have to be willing to compromise here; the 3.0.1
> compiler is going to be slower *and* probably generate slower code than
> 2.95, which is too bad, but that seems to be where we're at.  If we could
> get to 10-25% on both figures that would be better than having one figure
> small and the other massive.

The problem is, on both ends of the scale (that is, either slower code
or slower generation) the *better* value is already around 25%, so a
compromise will be worse than that for *both* values.

> Then, we continue working on Nathan/Daniel's stuff and hope to have it
> ready for 3.1, or maybe even 3.0.2.

That would be great.

A note to all interested parties: While, unfortunately, I cannot make
our sources and benchmark suite freely available (even though I'm trying
to convince my collaborators here at university to do so) I am definitely
willing to provide both to interested GCC developers.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.0.1 Status Report

[Marc Espie]

In article < 76410000.995505677@warlock.codesourcery.com > you write:
>We are nearing the pre-3.0.1 freeze.
>
>In particular, after midnight GMT - 0800 on July 21st, non-documentation 
>check-ins on the branch will require my approval.  I will make a release
>candidate at that time, for the planned August 1st release.

I'm still waiting for approval on the following patch...

http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00241.html

which you should have in your mailbox already.

Re: C++ compile-time regressions

[Gerald Pfeifer]

[ Includes patch. Okay for branch and mainline? ]

On Wed, 25 Jul 2001, Gerald Pfeifer wrote:
> Yes, I've been working on this now.  To be honest, I don't have time to
> do this, but I'll try to have something in time for 3.0.1 -- somehow.

So, here we go. (The first column is the value of PARAM_MAX_INLINE_INSNS.)

        -O2     -O3     -O2     -O3
 100    8:29    8:48    4000228 3990276
 500    8:24    8:53    4136996 4126148
 600    8:33    8:59    4158820 4156068
 700    8:52    9:32    4169028 4222436
 800    8:34?  10:27    4179652 4315396
1000    9:09   11:27    4239076 4425860
1500    9:49   14:05    4336260 4637060
2000   10:47   23:47    4435428 4758052

To me, 600 seems like a definite and affordable improvement here; I'd
be a bit hesitant to go over 700.

>> Realistically, I think we have to be willing to compromise here; the 3.0.1
>> compiler is going to be slower *and* probably generate slower code than
>> 2.95, which is too bad, but that seems to be where we're at.  If we could
>> get to 10-25% on both figures that would be better than having one figure
>> small and the other massive.
> The problem is, on both ends of the scale (that is, either slower code
> or slower generation) the *better* value is already around 25%, so a
> compromise will be worse than that for *both* values.

While I still see what I wrote as quoted above as a problem, here is the
patch I had promised.

I cannot perform regression testing anytime soon, so if this is required,
someone else has to do that and install the patch for me. I'll also try to
run detailed performance tests, but it's clear from previous results that
we will recover at least a bit.

Gerald

2001-08-01  Gerald Pfeifer  <pfeifer@dbai.tuwien.ac.at>

	* params.def (PARAM_MAX_INLINE_INSNS): Change default to 600.
	Correct comment that had been missed in the previous change.

Index: params.def
===================================================================
RCS file: /cvs/gcc/egcs/gcc/params.def,v
retrieving revision 1.3.2.5
diff -u -3 -p -r1.3.2.5 params.def
--- params.def	2001/07/26 13:55:02	1.3.2.5
+++ params.def	2001/08/02 05:45:02
@@ -39,12 +39,12 @@ Boston, MA 02111-1307, USA.
    function.  Increasing values mean more agressive inlining.
    This affects currently only functions explicitly marked as
    inline (or methods defined within the class definition for C++).
-   The default value of 10000 is arbitrary but high to match the
-   previously unlimited gcc capabilities.  */
+   The original default value of 10000 was arbitrary and caused
+   significant compile-time performance regressions.  */
 DEFPARAM (PARAM_MAX_INLINE_INSNS,
 	  "max-inline-insns",
 	  "The maximum number of instructions in a function that is eligible for inlining",
-	  100)
+	  600)

 /* The maximum number of instructions to consider when looking for an
    instruction to fill a delay slot.  If more than this arbitrary

Re: C++ compile-time regressions

[Mark Mitchell]

--On Thursday, August 02, 2001 09:19:42 AM +0200 Gerald Pfeifer 
<pfeifer@dbai.tuwien.ac.at> wrote:

> [ Includes patch. Okay for branch and mainline? ]
>
> On Wed, 25 Jul 2001, Gerald Pfeifer wrote:
>> Yes, I've been working on this now.  To be honest, I don't have time to
>> do this, but I'll try to have something in time for 3.0.1 -- somehow.

Approved for mainline and branch.  Thank you for doing the analysis.

Obviously, we all understand that this is a stopgap.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C++ compile-time regressions

[aoliva]

On Aug  2, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> [ Includes patch. Okay for branch and mainline? ]
> On Wed, 25 Jul 2001, Gerald Pfeifer wrote:
>> Yes, I've been working on this now.  To be honest, I don't have time to
>> do this, but I'll try to have something in time for 3.0.1 -- somehow.

> So, here we go. (The first column is the value of PARAM_MAX_INLINE_INSNS.)

> To me, 600 seems like a definite and affordable improvement here

Great!  Thanks for doing this.

But I wonder if the default value of PARAM_MAX_INLINE_INSNS should be
a property of the target machine.  Different targets have different
INSN densities.  I don't know how much this changes from one target to
another in the early rtl stages used for rtl inlining, though...  Does
anyone more experienced think it would be worth the trouble?  I could
produce a patch to make the default target-modifiable.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ compile-time regressions

[Mark Mitchell]

> But I wonder if the default value of PARAM_MAX_INLINE_INSNS should be
> a property of the target machine.  Different targets have different
> INSN densities.  I don't know how much this changes from one target to
> another in the early rtl stages used for rtl inlining, though...  Does
> anyone more experienced think it would be worth the trouble?  I could
> produce a patch to make the default target-modifiable.

I think we're tackling this from the wrong angle.  GCC uses about
3 to 4 times as much memory as it needs to, really, and our garbage
collector touches too many pages.  That combination is what it causing
a lot of the problems, in my profiling.  I know how to fix these
problems, I think, and I expect to start working on them soonish.

Anyhow, I guess I think we've done enough for now.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C++ compile-time regressions

[aoliva]

On Aug  2, 2001, Mark Mitchell <mark@codesourcery.com> wrote:

>> But I wonder if the default value of PARAM_MAX_INLINE_INSNS should be
>> a property of the target machine.  Different targets have different
>> INSN densities.  I don't know how much this changes from one target to
>> another in the early rtl stages used for rtl inlining, though...  Does
>> anyone more experienced think it would be worth the trouble?  I could
>> produce a patch to make the default target-modifiable.

> I think we're tackling this from the wrong angle.

I think I wasn't clear.  My suggestion didn't mean to affect compile
time, but rather, to offer a reasonably similar behavior across
multiple targets, in regards to inlining or not inlining functions.
Using the same threshold on targets with very different INSN densities
is deemed to get fewer functions inlined on targets with smaller INSN
densities.  I suppose it would be desirable to inline pretty much the
same functions, regardless of the target.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: C++ compile-time regressions

[Joe Buck]

Alexandre:
> >> But I wonder if the default value of PARAM_MAX_INLINE_INSNS should be
> >> a property of the target machine.  Different targets have different
> >> INSN densities.  I don't know how much this changes from one target to
> >> another in the early rtl stages used for rtl inlining, though...  Does
> >> anyone more experienced think it would be worth the trouble?  I could
> >> produce a patch to make the default target-modifiable.

Mark:
> > I think we're tackling this from the wrong angle.

Alexandre:
> I think I wasn't clear.  My suggestion didn't mean to affect compile
> time, but rather, to offer a reasonably similar behavior across
> multiple targets, in regards to inlining or not inlining functions.

But you're assuming that the current heuristic approach to inlining is
valid and only the parameter needs adjustment, and proposing a theory
about how it should be adjusted (normalize for instruction density)
without evidence that this is the right thing.

Re: C++ compile-time regressions

[Mark Mitchell]

--On Thursday, August 02, 2001 04:25:22 PM -0300 "aoliva@redhat.com" 
<aoliva@redhat.com> wrote:

> I suppose it would be desirable to inline pretty much the
> same functions, regardless of the target.

Yes, I suppose -- although if a function really is going to take up
twice as much icache on one platform as another, it might be a less
promising inlining candidate.

If you run some numbers and can show it's a win, then I think that's
good.  I wouldn't commit it without demonstrating the win, though.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: C++ compile-time regressions

[Joe Buck]

Alexandre:
> > I suppose it would be desirable to inline pretty much the
> > same functions, regardless of the target.

Mark:
> Yes, I suppose -- although if a function really is going to take up
> twice as much icache on one platform as another, it might be a less
> promising inlining candidate.

The compiler doesn't know the size of the user's icache, so it's hard
to make these tradeoffs: processors with lower instruction density might
well use bigger icaches to compensate.

> If you run some numbers and can show it's a win, then I think that's
> good.  I wouldn't commit it without demonstrating the win, though.

Agreed, we need numbers.  Gerald's tests are one source of inputs; there
also may be some code in Boost that could be used.

Re: C++ compile-time regressions

[Daniel Berlin]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> [ Includes patch. Okay for branch and mainline? ]
> 
> On Wed, 25 Jul 2001, Gerald Pfeifer wrote:
>> Yes, I've been working on this now.  To be honest, I don't have time to
>> do this, but I'll try to have something in time for 3.0.1 -- somehow.
> 
> So, here we go. (The first column is the value of PARAM_MAX_INLINE_INSNS.)
> 
>         -O2     -O3     -O2     -O3
>  100    8:29    8:48    4000228 3990276
>  500    8:24    8:53    4136996 4126148
>  600    8:33    8:59    4158820 4156068
>  700    8:52    9:32    4169028 4222436
>  800    8:34?  10:27    4179652 4315396
> 1000    9:09   11:27    4239076 4425860
> 1500    9:49   14:05    4336260 4637060
> 2000   10:47   23:47    4435428 4758052
> 
> To me, 600 seems like a definite and affordable improvement here; I'd
> be a bit hesitant to go over 700.
> 
>>> Realistically, I think we have to be willing to compromise here; the 3.0.1
>>> compiler is going to be slower *and* probably generate slower code than
>>> 2.95, which is too bad, but that seems to be where we're at.  If we could
>>> get to 10-25% on both figures that would be better than having one figure
>>> small and the other massive.
>> The problem is, on both ends of the scale (that is, either slower code
>> or slower generation) the *better* value is already around 25%, so a
>> compromise will be worse than that for *both* values.
> 
> While I still see what I wrote as quoted above as a problem, here is the
> patch I had promised.

BTW, i've gotten the performance problem down using a slightly
modified heuristic from
integrate.c.
On the last run, the compile times were about the same as 200 insns,
but the performance was *much* better (we're down to about 10% speed
loss).
When your performance gets shot to hell, it's always being caused by
not inlining things. I.E. at 100 insns, *::begin and *::end are taking
>50% of the runtime, because they aren't being inlined.

With a fixed store motion, we can turn off cse-skip-blocks and
cse-follow-jumps.
They buy us absolutely no gain, but cost a lot of time (In compiling
your app, Gerald, CSE accounts for > 20% of the compile time on the
files that take the longest to compile).
I've got statistics to back this up.
However, even with cse-skip-blocks and cse-follow-jumps turned off,
CSE is still >15% of the compile.
Mainly because it's trying to eliminate memory loads and stores, which
PRE and Store Motion do much faster than it (since they don't modify
the hash table when a store/load is killed, they just set a bit or two
in a bitvector), and on a global scale.
I'm just completing some benchmark runs to see if our performance
actually changes if i tell CSE to stop caring about memory (and run
store motion after reload).
I sincerely doubt it will, now that load and store motion should be
working.  
If it does, then PRE and store motion need to be improved. 

--Dan

-- 
"When I was a kid, I went to the store and asked the guy, "Do you
have any toy train schedules?"
"-Steven Wright

Re: C++ compile-time regressions

[Gerald Pfeifer]

On Thu, 2 Aug 2001, Mark Mitchell wrote:
> I think we're tackling this from the wrong angle.  GCC uses about
> 3 to 4 times as much memory as it needs to, really, and our garbage
> collector touches too many pages.

Well, I think we need to tackle it from several angles. :-)   Right now,
both compile-time and run-time performance are worse than GCC 2.95 (even
if we tune for either one).

> I know how to fix these problems, I think, and I expect to start
> working on them soonish.

That's excellent news, thanks!

> Anyhow, I guess I think we've done enough for now.

Daniel seems to have a promising patch, (a first draft of) which seems
very non-invasive and simple; this might be an excellent candidate for
GCC 3.0.2.

On Thu, 2 Aug 2001, Daniel Berlin wrote:
> BTW, i've gotten the performance problem down using a slightly
> modified heuristic from integrate.c. On the last run, the compile
> times were about the same as 200 insns, but the performance was *much*
> better (we're down to about 10% speed loss).

Excellent.

> When your performance gets shot to hell, it's always being caused by
> not inlining things. I.E. at 100 insns, *::begin and *::end are taking
> >50% of the runtime, because they aren't being inlined.

I guessed that something extremely bad like this was going on, because
performance was getting *that* bad.

Good to see both issues (compile-time and run-time performance) being
addressed. :-)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.0.1 Status Report

[Mark Mitchell]

--On Thursday, July 26, 2001 02:52:26 AM +0200 Marc Espie 
<espie@quatramaran.ens.fr> wrote:

> In article <76410000.995505677@warlock.codesourcery.com> you write:
>> We are nearing the pre-3.0.1 freeze.
>>
>> In particular, after midnight GMT - 0800 on July 21st, non-documentation
>> check-ins on the branch will require my approval.  I will make a release
>> candidate at that time, for the planned August 1st release.
>
> I'm still waiting for approval on the following patch...
>
> http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00241.html
>
> which you should have in your mailbox already.

Shoot -- I didn't remember to go back and deal with this message until
now.

The patch is OK.

Since the late approval is my fault, we'll chance incorporating the
patch.  Go ahead and check it in on the mainline.  On the branch,
please do not do the configure.in change, and adjust the mathconf.h
change to just do:

  #ifdef __OpenBSD__
     #include <sys/types.h>
  #endif

in the appropriate place.  Ugly, but very safe, and safety first
at this stage.  Please test that to confirm it works.

Please apply this patch ASAP and let me know when you have applied
it.  Then, I will respin.

Thank you,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com