Re: [PATCH] Drop callee function size limits for IPA inlining

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> Sure.  But I don't think you can easily reach the unit growth limit
> that way, and if you do then people can simply use -finline-limit
> which will then do what they expect.  Btw, you can't have all of it,

This was precisely what I saw in kernel - tiny .c file with some stuff with
few functions marked inline that after inlining makes unit growth.

> allow growing units very large for such reason and at the same time
> complain that we grow the units 30% all the time ;)

Well, that is why I think unit growth alone is not best way to control inliner
:)

By removing the size limits that prevents inlining will push unit growth down
that in turn penalize cases that really do need it.  Surely heruistics by
nature can't give optimal results everywhere, but we want heuristics that is
doing well overall. But we will see what will fare best later.

> 
> But usually it is the larger units that contain performance critical
> parts (or you'd have to use LTO anyway to do cross module inlining).

Hmm, why?  When you have app, like my fractal zooming, where the internal loop
is naturally simple and self contained, it is perfectly normal to have it in
its own small compilation unit.

I would expect quite few programs to be organized that way.
> 
> No, --param stuff is for developers and hackers ;)  There are way too
> may parameters when usually people just want "more inlining" to happen.

Use inline and always_inline then ;)
> > 
> > gigantic_function1() {....}
> > gigantic_function2() {....}
> > gigantic_function3() {....}
> > simple_wrapper () {gigantic_function1();}
> > 
> > If gigantic function is, lets say, 200kb of code, I would argue that we do not
> > want to regress 30% compile time and code size on this.  I guess this appears
> > i.e. in our insn-* stuff at -O3.
> 
> That's we have the (large) function growth limits for.  I didn't (and do
> not plan to) remove those.

large function growth do allow inlining gigantic function into tiny as they are based
on larger of both.  This is to i.e. allow inlining gigantic function called once.
This is often good idea.
> 
> Sure it would.  We'd at most inline one gigantic function into
> simple_wrapper, and only if gigantic function will go away then.

We will inline even if gigantic_function is exported from unit since there are
3 gigantic functions and duplicating one leads to only 30% unit growth.

> That's precisely why we have that size inversion check, no?

size inversion check?
> >    - better benefit analysis driven by knowledge of arguments
> 
> Yeah, happy to see patches for this ;)

Martin has them, but they will need updating.
> 
> >    - introduce the edge want predicate
> 
> That I'd consider "cleanup", simply factor out existing checks without
> functional changes.  I'll do that.
> 
> I'd add
> 
>      - add early FRE
> 
> because in the end we want that and want to do all tuning based on
> a tree with that in.

Yep, agreed.
> 
> Fortran has no notion of "inline" functions, and I'm not sure people
> do not care about size at -O2.  I'd rather have us more aggressively
> inline for -finline-functions (and thus -O3), currently it's basically
> a no-op, even for C programs.

Not really no-op, -O3 binaries are considerably bigger and we do quite a lot
of inlining.

It is all about finding resonable code size/performance tradeoff here.  It is
obviously difficult to meet everyone needs here. But I would think that if you
allow me 10-20% code size and compilation time growth at -O3 SPEC, i will find
way to improve it more than by 0.3%.  So at least the current prototype don't
seem to be win in general at least in my POV.

I duno - lets see if we find way to tune inliner that makes everyone resonably
(un)happy.  Going for language specific parameters is one of last resorts I
would try.  In general it seems slipperly idea - even if different languages
have different dominant coding styles.  We went through the discussion about
language specific parameter changes several times in the past and always found
way to make the inliner heuristics adapt without those hints.

Honza
> 
> Richard.