* GCC 3.0.1 Status Report @ 2001-07-18 18:41 Mark Mitchell 2001-07-19 6:17 ` Joseph S. Myers ` (3 more replies) 0 siblings, 4 replies; 49+ messages in thread From: Mark Mitchell @ 2001-07-18 18:41 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GCC 3.0.1 Status Report 2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell @ 2001-07-19 6:17 ` Joseph S. Myers 2001-07-20 3:45 ` Nathan Sidwell ` (2 subsequent siblings) 3 siblings, 0 replies; 49+ messages in thread From: Joseph S. Myers @ 2001-07-19 6:17 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GCC 3.0.1 Status Report 2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell 2001-07-19 6:17 ` Joseph S. Myers @ 2001-07-20 3:45 ` Nathan Sidwell 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer 2001-07-25 17:52 ` GCC 3.0.1 Status Report Marc Espie 3 siblings, 0 replies; 49+ messages in thread From: Nathan Sidwell @ 2001-07-20 3:45 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell 2001-07-19 6:17 ` Joseph S. Myers 2001-07-20 3:45 ` Nathan Sidwell @ 2001-07-20 10:26 ` Gerald Pfeifer 2001-07-20 10:54 ` Nathan Sidwell ` (3 more replies) 2001-07-25 17:52 ` GCC 3.0.1 Status Report Marc Espie 3 siblings, 4 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-20 10:26 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer @ 2001-07-20 10:54 ` Nathan Sidwell 2001-07-20 16:41 ` Loren James Rittle 2001-07-23 2:51 ` Gerald Pfeifer 2001-07-20 10:55 ` Mark Mitchell ` (2 subsequent siblings) 3 siblings, 2 replies; 49+ messages in thread From: Nathan Sidwell @ 2001-07-20 10:54 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Mark Mitchell, gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:54 ` Nathan Sidwell @ 2001-07-20 16:41 ` Loren James Rittle 2001-07-23 5:17 ` Gerald Pfeifer 2001-07-23 11:56 ` Daniel Berlin 2001-07-23 2:51 ` Gerald Pfeifer 1 sibling, 2 replies; 49+ messages in thread From: Loren James Rittle @ 2001-07-20 16:41 UTC (permalink / raw) To: gcc; +Cc: 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 16:41 ` Loren James Rittle @ 2001-07-23 5:17 ` Gerald Pfeifer 2001-07-23 11:56 ` Daniel Berlin 1 sibling, 0 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-23 5:17 UTC (permalink / raw) To: Loren James Rittle; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 16:41 ` Loren James Rittle 2001-07-23 5:17 ` Gerald Pfeifer @ 2001-07-23 11:56 ` Daniel Berlin 1 sibling, 0 replies; 49+ messages in thread From: Daniel Berlin @ 2001-07-23 11:56 UTC (permalink / raw) To: Loren James Rittle; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:54 ` Nathan Sidwell 2001-07-20 16:41 ` Loren James Rittle @ 2001-07-23 2:51 ` Gerald Pfeifer 1 sibling, 0 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-23 2:51 UTC (permalink / raw) To: Nathan Sidwell; +Cc: Mark Mitchell, gcc 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer 2001-07-20 10:54 ` Nathan Sidwell @ 2001-07-20 10:55 ` Mark Mitchell 2001-07-20 14:22 ` Joe Buck 2001-07-20 10:57 ` Daniel Berlin 2001-07-20 14:20 ` Joe Buck 3 siblings, 1 reply; 49+ messages in thread From: Mark Mitchell @ 2001-07-20 10:55 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:55 ` Mark Mitchell @ 2001-07-20 14:22 ` Joe Buck 2001-07-20 16:28 ` Mark Mitchell 0 siblings, 1 reply; 49+ messages in thread From: Joe Buck @ 2001-07-20 14:22 UTC (permalink / raw) To: Mark Mitchell; +Cc: pfeifer 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 14:22 ` Joe Buck @ 2001-07-20 16:28 ` Mark Mitchell 2001-07-20 21:05 ` Joe Buck 0 siblings, 1 reply; 49+ messages in thread From: Mark Mitchell @ 2001-07-20 16:28 UTC (permalink / raw) To: Joe Buck; +Cc: Gerald Pfeifer, gcc > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 16:28 ` Mark Mitchell @ 2001-07-20 21:05 ` Joe Buck 2001-07-23 10:44 ` Gerald Pfeifer 0 siblings, 1 reply; 49+ messages in thread From: Joe Buck @ 2001-07-20 21:05 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, pfeifer 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? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 21:05 ` Joe Buck @ 2001-07-23 10:44 ` Gerald Pfeifer 2001-07-23 11:12 ` Joe Buck 2001-07-23 11:54 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Daniel Berlin 0 siblings, 2 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-23 10:44 UTC (permalink / raw) To: Mark Mitchell, Joe Buck; +Cc: gcc 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 10:44 ` Gerald Pfeifer @ 2001-07-23 11:12 ` Joe Buck 2001-07-23 11:57 ` Gerald Pfeifer 2001-07-23 11:54 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Daniel Berlin 1 sibling, 1 reply; 49+ messages in thread From: Joe Buck @ 2001-07-23 11:12 UTC (permalink / raw) To: pfeifer; +Cc: Mark Mitchell, Joe Buck, gcc 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. :-) ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 11:12 ` Joe Buck @ 2001-07-23 11:57 ` Gerald Pfeifer 2001-07-23 13:30 ` Joe Buck 2001-07-23 14:36 ` Mark Mitchell 0 siblings, 2 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-23 11:57 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, gcc [-- 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 11:57 ` Gerald Pfeifer @ 2001-07-23 13:30 ` Joe Buck 2001-07-24 7:18 ` Gerald Pfeifer 2001-07-23 14:36 ` Mark Mitchell 1 sibling, 1 reply; 49+ messages in thread From: Joe Buck @ 2001-07-23 13:30 UTC (permalink / raw) To: pfeifer; +Cc: Joe Buck, Mark Mitchell, gcc 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? ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 13:30 ` Joe Buck @ 2001-07-24 7:18 ` Gerald Pfeifer 2001-07-24 7:55 ` Daniel Berlin 2001-07-24 10:09 ` Joe Buck 0 siblings, 2 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-24 7:18 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, gcc 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 7:18 ` Gerald Pfeifer @ 2001-07-24 7:55 ` Daniel Berlin 2001-07-24 10:09 ` Joe Buck 1 sibling, 0 replies; 49+ messages in thread From: Daniel Berlin @ 2001-07-24 7:55 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Joe Buck, Mark Mitchell, gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 7:18 ` Gerald Pfeifer 2001-07-24 7:55 ` Daniel Berlin @ 2001-07-24 10:09 ` Joe Buck 2001-07-24 10:19 ` Gabriel Dos Reis 2001-07-24 10:25 ` Daniel Berlin 1 sibling, 2 replies; 49+ messages in thread From: Joe Buck @ 2001-07-24 10:09 UTC (permalink / raw) To: pfeifer; +Cc: Joe Buck, Mark Mitchell, gcc > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 10:09 ` Joe Buck @ 2001-07-24 10:19 ` Gabriel Dos Reis 2001-07-24 10:44 ` Joe Buck 2001-07-24 10:25 ` Daniel Berlin 1 sibling, 1 reply; 49+ messages in thread From: Gabriel Dos Reis @ 2001-07-24 10:19 UTC (permalink / raw) To: Joe Buck; +Cc: pfeifer 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 10:19 ` Gabriel Dos Reis @ 2001-07-24 10:44 ` Joe Buck 2001-07-24 10:56 ` Gabriel Dos Reis 0 siblings, 1 reply; 49+ messages in thread From: Joe Buck @ 2001-07-24 10:44 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Joe Buck, pfeifer > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 10:44 ` Joe Buck @ 2001-07-24 10:56 ` Gabriel Dos Reis 0 siblings, 0 replies; 49+ messages in thread From: Gabriel Dos Reis @ 2001-07-24 10:56 UTC (permalink / raw) To: Joe Buck; +Cc: Gabriel Dos Reis, pfeifer 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 10:09 ` Joe Buck 2001-07-24 10:19 ` Gabriel Dos Reis @ 2001-07-24 10:25 ` Daniel Berlin 2001-07-24 10:49 ` Joe Buck 1 sibling, 1 reply; 49+ messages in thread From: Daniel Berlin @ 2001-07-24 10:25 UTC (permalink / raw) To: Joe Buck; +Cc: pfeifer 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 10:25 ` Daniel Berlin @ 2001-07-24 10:49 ` Joe Buck 2001-07-24 11:08 ` Daniel Berlin 0 siblings, 1 reply; 49+ messages in thread From: Joe Buck @ 2001-07-24 10:49 UTC (permalink / raw) To: Daniel Berlin; +Cc: Joe Buck, pfeifer > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-24 10:49 ` Joe Buck @ 2001-07-24 11:08 ` Daniel Berlin 0 siblings, 0 replies; 49+ messages in thread From: Daniel Berlin @ 2001-07-24 11:08 UTC (permalink / raw) To: Joe Buck; +Cc: Daniel Berlin, pfeifer 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 11:57 ` Gerald Pfeifer 2001-07-23 13:30 ` Joe Buck @ 2001-07-23 14:36 ` Mark Mitchell 2001-07-25 8:06 ` Gerald Pfeifer 1 sibling, 1 reply; 49+ messages in thread From: Mark Mitchell @ 2001-07-23 14:36 UTC (permalink / raw) To: Gerald Pfeifer, Joe Buck; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 14:36 ` Mark Mitchell @ 2001-07-25 8:06 ` Gerald Pfeifer 2001-08-02 0:20 ` C++ compile-time regressions Gerald Pfeifer 0 siblings, 1 reply; 49+ messages in thread From: Gerald Pfeifer @ 2001-07-25 8:06 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, gcc 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-07-25 8:06 ` Gerald Pfeifer @ 2001-08-02 0:20 ` Gerald Pfeifer 2001-08-02 0:26 ` Mark Mitchell ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-08-02 0:20 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, gcc, gcc-patches [ 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 0:20 ` C++ compile-time regressions Gerald Pfeifer @ 2001-08-02 0:26 ` Mark Mitchell 2001-08-02 11:00 ` aoliva 2001-08-02 13:53 ` Daniel Berlin 2 siblings, 0 replies; 49+ messages in thread From: Mark Mitchell @ 2001-08-02 0:26 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Joe Buck, gcc, gcc-patches --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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 0:20 ` C++ compile-time regressions Gerald Pfeifer 2001-08-02 0:26 ` Mark Mitchell @ 2001-08-02 11:00 ` aoliva 2001-08-02 12:00 ` Mark Mitchell 2001-08-02 13:53 ` Daniel Berlin 2 siblings, 1 reply; 49+ messages in thread From: aoliva @ 2001-08-02 11:00 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Mark Mitchell, Joe Buck, gcc, gcc-patches 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 11:00 ` aoliva @ 2001-08-02 12:00 ` Mark Mitchell 2001-08-02 12:26 ` aoliva 0 siblings, 1 reply; 49+ messages in thread From: Mark Mitchell @ 2001-08-02 12:00 UTC (permalink / raw) To: aoliva, Gerald Pfeifer; +Cc: Joe Buck, gcc, gcc-patches > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 12:00 ` Mark Mitchell @ 2001-08-02 12:26 ` aoliva 2001-08-02 12:37 ` Joe Buck 2001-08-02 12:41 ` Mark Mitchell 0 siblings, 2 replies; 49+ messages in thread From: aoliva @ 2001-08-02 12:26 UTC (permalink / raw) To: Mark Mitchell; +Cc: Gerald Pfeifer, Joe Buck, gcc, gcc-patches 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 12:26 ` aoliva @ 2001-08-02 12:37 ` Joe Buck 2001-08-02 12:41 ` Mark Mitchell 1 sibling, 0 replies; 49+ messages in thread From: Joe Buck @ 2001-08-02 12:37 UTC (permalink / raw) To: aoliva; +Cc: Mark Mitchell, pfeifer 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 12:26 ` aoliva 2001-08-02 12:37 ` Joe Buck @ 2001-08-02 12:41 ` Mark Mitchell 2001-08-02 12:48 ` Joe Buck 1 sibling, 1 reply; 49+ messages in thread From: Mark Mitchell @ 2001-08-02 12:41 UTC (permalink / raw) To: aoliva; +Cc: Gerald Pfeifer, Joe Buck, gcc, gcc-patches --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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 12:41 ` Mark Mitchell @ 2001-08-02 12:48 ` Joe Buck 0 siblings, 0 replies; 49+ messages in thread From: Joe Buck @ 2001-08-02 12:48 UTC (permalink / raw) To: Mark Mitchell; +Cc: aoliva, pfeifer 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 0:20 ` C++ compile-time regressions Gerald Pfeifer 2001-08-02 0:26 ` Mark Mitchell 2001-08-02 11:00 ` aoliva @ 2001-08-02 13:53 ` Daniel Berlin 2001-08-07 7:54 ` Gerald Pfeifer 2 siblings, 1 reply; 49+ messages in thread From: Daniel Berlin @ 2001-08-02 13:53 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Mark Mitchell, Joe Buck, gcc, gcc-patches 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-02 13:53 ` Daniel Berlin @ 2001-08-07 7:54 ` Gerald Pfeifer 0 siblings, 0 replies; 49+ messages in thread From: Gerald Pfeifer @ 2001-08-07 7:54 UTC (permalink / raw) To: Mark Mitchell, Daniel Berlin; +Cc: aoliva, Joe Buck, gcc, gcc-patches 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 10:44 ` Gerald Pfeifer 2001-07-23 11:12 ` Joe Buck @ 2001-07-23 11:54 ` Daniel Berlin 2001-07-23 12:42 ` Bernd Schmidt 2001-07-23 12:50 ` law 1 sibling, 2 replies; 49+ messages in thread From: Daniel Berlin @ 2001-07-23 11:54 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Mark Mitchell, Joe Buck, gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 11:54 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Daniel Berlin @ 2001-07-23 12:42 ` Bernd Schmidt 2001-07-23 12:50 ` law 1 sibling, 0 replies; 49+ messages in thread From: Bernd Schmidt @ 2001-07-23 12:42 UTC (permalink / raw) To: Daniel Berlin; +Cc: Gerald Pfeifer, Mark Mitchell, Joe Buck, gcc > > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 11:54 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Daniel Berlin 2001-07-23 12:42 ` Bernd Schmidt @ 2001-07-23 12:50 ` law 2001-07-23 13:15 ` Daniel Berlin 1 sibling, 1 reply; 49+ messages in thread From: law @ 2001-07-23 12:50 UTC (permalink / raw) To: Daniel Berlin; +Cc: Gerald Pfeifer, Mark Mitchell, Joe Buck, gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 12:50 ` law @ 2001-07-23 13:15 ` Daniel Berlin 2001-07-23 14:00 ` law 0 siblings, 1 reply; 49+ messages in thread From: Daniel Berlin @ 2001-07-23 13:15 UTC (permalink / raw) To: law; +Cc: Gerald Pfeifer, Mark Mitchell, Joe Buck, gcc --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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-23 13:15 ` Daniel Berlin @ 2001-07-23 14:00 ` law 0 siblings, 0 replies; 49+ messages in thread From: law @ 2001-07-23 14:00 UTC (permalink / raw) To: Daniel Berlin; +Cc: Gerald Pfeifer, Mark Mitchell, Joe Buck, gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer 2001-07-20 10:54 ` Nathan Sidwell 2001-07-20 10:55 ` Mark Mitchell @ 2001-07-20 10:57 ` Daniel Berlin 2001-07-20 14:20 ` Joe Buck 3 siblings, 0 replies; 49+ messages in thread From: Daniel Berlin @ 2001-07-20 10:57 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: Mark Mitchell, gcc 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions (was: GCC 3.0.1 Status Report) 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer ` (2 preceding siblings ...) 2001-07-20 10:57 ` Daniel Berlin @ 2001-07-20 14:20 ` Joe Buck 3 siblings, 0 replies; 49+ messages in thread From: Joe Buck @ 2001-07-20 14:20 UTC (permalink / raw) To: pfeifer; +Cc: Mark Mitchell, gcc > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GCC 3.0.1 Status Report 2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell ` (2 preceding siblings ...) 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer @ 2001-07-25 17:52 ` Marc Espie 2001-08-13 23:15 ` Mark Mitchell 3 siblings, 1 reply; 49+ messages in thread From: Marc Espie @ 2001-07-25 17:52 UTC (permalink / raw) To: mark; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: GCC 3.0.1 Status Report 2001-07-25 17:52 ` GCC 3.0.1 Status Report Marc Espie @ 2001-08-13 23:15 ` Mark Mitchell 0 siblings, 0 replies; 49+ messages in thread From: Mark Mitchell @ 2001-08-13 23:15 UTC (permalink / raw) To: Marc Espie; +Cc: gcc --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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions @ 2001-08-03 6:53 Richard Kenner 2001-08-03 10:20 ` Daniel Berlin 0 siblings, 1 reply; 49+ messages in thread From: Richard Kenner @ 2001-08-03 6:53 UTC (permalink / raw) To: dan; +Cc: gcc-patches, gcc 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). As far as I know, CSE is the only pass which knows the precise semantics of when memory locations conflict. Remember that they aren't equivalence classes. ^ permalink raw reply [flat|nested] 49+ messages in thread
* Re: C++ compile-time regressions 2001-08-03 6:53 C++ compile-time regressions Richard Kenner @ 2001-08-03 10:20 ` Daniel Berlin 0 siblings, 0 replies; 49+ messages in thread From: Daniel Berlin @ 2001-08-03 10:20 UTC (permalink / raw) To: Richard Kenner; +Cc: gcc-patches, gcc --On Friday, August 03, 2001 9:58 AM -0400 Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote: > 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). > > As far as I know, CSE is the only pass which knows the precise > semantics of when memory locations conflict. Remember that they aren't > equivalence classes. 'fraid not. Both PRE and store motion know precisely when they conflict (I.E. they use true_dependence), and when they aren't available/antic (I.E. Their register operands changed). It's faster because it doesn't require removing from a hash table, just setting or resetting a bit in a bitvector. --Dan ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2001-08-13 23:15 UTC | newest] Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-07-18 18:41 GCC 3.0.1 Status Report Mark Mitchell 2001-07-19 6:17 ` Joseph S. Myers 2001-07-20 3:45 ` Nathan Sidwell 2001-07-20 10:26 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Gerald Pfeifer 2001-07-20 10:54 ` Nathan Sidwell 2001-07-20 16:41 ` Loren James Rittle 2001-07-23 5:17 ` Gerald Pfeifer 2001-07-23 11:56 ` Daniel Berlin 2001-07-23 2:51 ` Gerald Pfeifer 2001-07-20 10:55 ` Mark Mitchell 2001-07-20 14:22 ` Joe Buck 2001-07-20 16:28 ` Mark Mitchell 2001-07-20 21:05 ` Joe Buck 2001-07-23 10:44 ` Gerald Pfeifer 2001-07-23 11:12 ` Joe Buck 2001-07-23 11:57 ` Gerald Pfeifer 2001-07-23 13:30 ` Joe Buck 2001-07-24 7:18 ` Gerald Pfeifer 2001-07-24 7:55 ` Daniel Berlin 2001-07-24 10:09 ` Joe Buck 2001-07-24 10:19 ` Gabriel Dos Reis 2001-07-24 10:44 ` Joe Buck 2001-07-24 10:56 ` Gabriel Dos Reis 2001-07-24 10:25 ` Daniel Berlin 2001-07-24 10:49 ` Joe Buck 2001-07-24 11:08 ` Daniel Berlin 2001-07-23 14:36 ` Mark Mitchell 2001-07-25 8:06 ` Gerald Pfeifer 2001-08-02 0:20 ` C++ compile-time regressions Gerald Pfeifer 2001-08-02 0:26 ` Mark Mitchell 2001-08-02 11:00 ` aoliva 2001-08-02 12:00 ` Mark Mitchell 2001-08-02 12:26 ` aoliva 2001-08-02 12:37 ` Joe Buck 2001-08-02 12:41 ` Mark Mitchell 2001-08-02 12:48 ` Joe Buck 2001-08-02 13:53 ` Daniel Berlin 2001-08-07 7:54 ` Gerald Pfeifer 2001-07-23 11:54 ` C++ compile-time regressions (was: GCC 3.0.1 Status Report) Daniel Berlin 2001-07-23 12:42 ` Bernd Schmidt 2001-07-23 12:50 ` law 2001-07-23 13:15 ` Daniel Berlin 2001-07-23 14:00 ` law 2001-07-20 10:57 ` Daniel Berlin 2001-07-20 14:20 ` Joe Buck 2001-07-25 17:52 ` GCC 3.0.1 Status Report Marc Espie 2001-08-13 23:15 ` Mark Mitchell 2001-08-03 6:53 C++ compile-time regressions Richard Kenner 2001-08-03 10:20 ` Daniel Berlin
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).