Partial inlining

[Jan Hubicka]

> > Well, at -O2 it splits only functions declared inline so it should not be
> > terribly back (i.e. it does not show as slowdown at our testers).
> > One option would be to further limit splitting only when call to split part
> > is cold or it makes previously uninlinable function inlinable so the
> > degenerate case of splitting and re-combining does not happen.
> 
> OK, but historically we have restricted sophisticated optimizations to -O3.
> I think users will be surprised when they discover that their small inline 
> functions are broken apart at -O2 without clear reasons.  The recent problems 
> with 4.5 show that computing good inlining estimates is relatively hard.

I would say that -O3 is more about risky optimizations.  Those that might not
help or make aggressive tradeoffs in between size and speed.  We definitly do a
lot of smart things at -O2 that might surprise users.  For example type based
aliasing.  (or at IPA we introduced autoinlining for size in 4.3, cloning in
4.4 and more).

Partial inlining should not be risky in this way. It does not make programs
bigger. And the problems with tuning inliner is partly reason why I worked on
the pass - tuning is so hard because we mis other useful transforms otherwise.
Inline limits are pushed up by few benchmarks that reuiqre inlining very large
functions that, some of them can be cured with partial inlining and other
compilers do partial inlining by default too.

I agree that in current setting the pass is too active.  It helps to identify
issues and then it should be easy to selectively trottle it at -O2 (and partly
at -O3 too) while retuning inliner later in development of 4.6.

Honza
> 
> > Jakub sent me a testcase where similarly funny thing happen, there it is
> > because the split part has frequency of 0 everywhere (it is guarted by
> > builtin_expect). This confuses inliner herusitic by concluding that time
> > spent in function is 0 and savings is a call cost (a roundof error to
> > prevent division by zero). I will work on fixing that one first hopefully
> > fixing this one too.
> 
> Thanks in advance.
> 
> -- 
> Eric Botcazou