This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi Dale, On Wed, Sep 04, 2002 at 10:18:05AM -0700, Dale Johannesen wrote: > On Wednesday, September 4, 2002, at 12:11 AM, Kurt Garloff wrote: > The main trunk at gcc.gnu.org:/cvs/gcc. If there's another version > somewhere that has these things fixed, it needs to be applied here, > I think. Well, in my patch collection at http://www.garloff.de/kurt/freesoft/gcc/ there are patches for documentation included. But only in the newer patches, and I'm afriad an older one went into gcc. > I haven't tried it, but it looks like this change > > > read_integral_parameter (option_value, arg - 2, > > MAX_INLINE_INSNS); > > > > set_param_value ("max-inline-insns", val); > > set_param_value ("max-inline-insns-single", val/2); > > alters the meaning of -finline-limit from what it was previously (i.e. > the size limit for an individual function is half what it was). I think > that needs some discussion, at a minimum. In 2.95, it was defaulting to 10000, which means that no real-world function was prevented from being inlined. Which could cause excessive memory and CPU consumption for compiling fairly easy code in C++. The inliner in 2.95 did not account for recursive inlining. 3.0 had the tree inliner and was accounting for recursive inlining. It limited your total inlining budget to 1000 statements. (The parameter was still at 10000, but one statement was assumed to be aequivalent to 10 RTL insns.) This resulted in extreme compile resource requirements even for less pathological C++ code, just because the tree inliner has less restriction than the old RTL one. The performance was still worse than 2.95. In 3.0.1 this was changed to 600 (i.e. 60 statements) after 100 (10st) showed desastrous performance. With 600, compile times were OK, but runtime performance was poor. http://gcc.gnu.org/ml/gcc/2001-07/msg01531.html Only then, the problem was identified http://gcc.gnu.org/ml/gcc/2001-08/msg00996.html to be caused by the wrong functions being inlined, as we allow single functions to eat up the complete inlining budget, which calls for wrong inlining decisions, of course. A little patch solved it. http://gcc.gnu.org/ml/gcc/2001-08/msg01114.html Since that moment, the notion of a different single function inlining limit as compared to the recursive inlining limit exists and I chose half the complete by default. -finline-limit in 3.0 meant the complete inlining budget which was identical to the single function inline size and it could only keep one meaning after the patch was applied obviously. The limit of 600 in 3.0.1 worked very well when used as complete budget with a single fn limit of 300, so I took that decision. The patch was improved a lot afterwards by applying some smooth function that restricted inlining as a smooth decreasing function of the already inlined code, so more parameters were possible. I did lots of bench- marking, but the improvement on the first patch was not as huge as the first patch itself. Anyway, I was expecting a lot of discussion when posting my patches on the gcc list, but I got less reactions than expected. Maybe gcc folks were not so interested in C++ performance or were just happy with the suggestions. > (If anybody's lost, the patch was discussed in Aug 01 and later in > Apr/May 02; most of the discussion was on gcc, not gcc-patches. > The discussion does mention documentation changes but they don't > seem to have been checked in. That's a pity. > I'm having a little trouble tracking > this; Kurt Garloff isn't in MAINTAINERS, so I wonder if somebody > checked this in for him?) No, I'm not a gcc MAINTAINER. I lack the time to concentrate on gcc work and I think there are others who are more qualified than me. I believe the first version of the patch got checked in by Gerald. I don't know what other versions went in later and who did the check ins. Maybe nobody told me, maybe I don't remember. But, if this discussion is starting up again, I would like to propose my patch v4 (from the above webpage) for inclusion. I would appreciate a lot to get (positive and negative) criticism on it. If somebody would like to have the patches rediffed against current CVS, I can provide those. PS: Dale, if you're seriously starting to look at the inlining code and you happen to have a bit of time, please go ahead and improve the heuristics. One of the most obvious optimizations is keeping track of the level (and the estimated iteration count) of loops we're called from. Take it into account when taking an inlining decision. It's easy yet very efficient. Next improvement would be to calculate the complete call graph and then take decisions on where to cut it based on inlining limits, loop depth and function size. There you would probably start with inlining from the leaf functions not the trunk. This is slightly more work, obviously. I guess the importance of inlinig heuristics has been underestimated previously. Maybe due to the fact that people were focused on C which does not make such heavy use of inlining as C++ (and other OOP lan- guages). Best regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE Linux AG, Nuernberg, DE SCSI, Security
Attachment:
msg00143/pgp00000.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |