Hi Gerald, thanks for testing! On Thu, Apr 25, 2002 at 06:36:10PM +0200, Gerald Pfeifer wrote: > On Wed, 24 Apr 2002, Kurt Garloff wrote: > > It would be nice if this patch > > http://www.garloff.de/kurt/freesoft/gcc/gcc310-inline-func-acct-v1.diff > > would be tested by more people and integrated into 3.1. > > This second patch (partially) fixes a very bad regression we've been > having since GCC 3.0; build time and binary size seem to be fine, though > we seem to degrade slightly for some of the other benchmarks. > > I'd really like to see what this does to SPEC -- Andreas, could you give > it a try? Actually, maybe we should wait a second. When I developed the patch on 3.0.1, I was not seeing the degradation you see now for some benchmarks. So I must have done some mistake when porting it from 3.0.1 to 3.1, or some assumption I made is not true any more. I've done some more benchmarks with this inline accounting patch and I also have found a case with performance regression against v3, even without -finline-functions, so something must have gone wrong I think. What I try to do in the patch is to improve -O3 (-finline-functions) performance. The idea is to keep the information whether a function was declared inline or whether it got inlined by virtue of the automatic inlining. I may have screwed this up ... and set the flag when it should not, so we actually treat the inline declared function with the lower automatic limit. (a) The declared inline fn would get the full 300/600 limit whereas the automatically inlined ones only half. [The idea is that we still think the programmer has a bit of a clue. Maybe the factor 0.5 is a bit too strict.] The patch also does two other things that have proven useful on 2.95.3 (b) better tune -Os (again tested on i386) (c) give leaf functions a bonus (*3/2) in the RTL inliner [is it still used at all?] Maybe one should separate those issues and verify that do what my intention was. I would certainly appreciate if somebody with some more knowledge of the compiler internals would have a look. Any takers? > (This is due to a C module in the C++ application, and your fix seems > to be critical for many C applications in general.) > > build time binary size > 2.95.3 4:01 4430752 > 3.0 23:54 6295044 > 3.0.3 3:58 3948444 > 3.1-20020422 4:38 3996096 <-- without patch > 3.1-20020424+kurt-v3 5:35 4102432 > 3.1.20020425+kurt-finl. 4:32 3912640 <-- this is with the patch This is with both patches I assume. I'm astonished we beat plain 0422 at build time and binary size. But the benchmark results do not really look attractive to me. We only win one benchmark against -v3, and even against plain we sometimes lose. Regards, -- Kurt Garloff Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security