> On Mon, Jan 9, 2012 at 12:07 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> > >> That surely should be MAX_INLINE_INSNS_AUTO instead. At _least_. > >> You are triggering very much more inlining during early inlining now - > >> I don't see > >> where we did this for -Os already as you claim. In fact it is totally > >> against the spirit of early inlining now :( > > > > This is IPA inlining, not early inlining. I just moved the logic from -Os > > logic > > to include -O2 logic, too. > > Ok, I was confused then. But as you re-order the tests this exception > will apply always, no?
Yes, for all sorts of auto inlining we have. It makes sense now. When the code was written we did not have indirect inlining, did not special case comdats and did not have the context sensitivity, so it was safe to first do all small function inlining and later all inlining of all functions called once. Now order matters, by deferring even relatively small functions for very end we loose the context sensitivity, like in the testcase discussed. > > > I added the size check because I was worried of units containing one very > > large > > function that simplifies quite a lot by inlining (because of the new > > predicate > > code). Because badness function is not really worried about function sizes > > (it > > expects them to be small) and merely accounts relative benefits, we would > > end > > up then inlining this large function quite early in queue preventing other > > inlining from happening. > > > > So it seemed safer to add the size check. Except the degenerate case > > described > > above it should not make much of practical difference. > > But the size check is inconsistent wrt inline declares, non-inline declared > fns should get the _auto limit. Not really, I want even _auto limit to be bypassed in this case. We may introduce new parameter for this, but _single limit is resonably big and available and we do have too many parameters already. Well, this hits the problem that the limits as written does not make that good sense with the inliner logic as it works now. As i think about it now we have three basic cases. 1) We do have cases where we inline just to reduce size. This is quite clear and don't really need a parameter. 2) We have case where we inline just because we do -O3 and we don't see particular benefit of inlining but we will reduce call overhead and we may hope that something simplifies later. This is sort of what current _auto limit serves. 3) We know that inlining will be a win - either by profile, or by user hint, or by fact that we know a lot of code will optimize out, or we know call will devirtualize, or we know that program will not grow etc. etc. This is sort of what current _single limit serves, but not really well, since the benefits have different importance... Honza
