[Bug lto/54966] Does LTO requires a larger inline-unit-growth?

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966

--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> 2012-10-23 14:12:43 UTC ---
The patch suggesed by Dminique is not going to help here.

> I was just guessing why our overall unit-growth heuristics would
> lead to different overall inlining with LTO vs. single TUs.

Well, the situation is usually as follow.  You have relatively large X that
needs inlining into Y in an unit that contains few extra inlining candidates
(usually smaller than Y).

When compiling without/LTO the inliner do not hit the unit-growth limit at all
because there are relatively few candidates and Y is one of them.

With LTO there are very many cross module inlining candidates.  Many of htem
will end up in the priority queue before Y and consequentely Y may fall out of
the threshold.

Just the common case we discussed many times when you make inliner's
profitability based mostly on the global properties of the program.

One way I handled this is to introduce inliner's hints to prioritize inlining
of large functions that seems profitable for other reasons. (so it may be worth
trying 4.8 and see if it fares better and if not giving me some example on how
the function to be inlined looks like)

Other thing I wondered about is possibility of increasing badness of cross
module inlining counting on the fact that programs are usually organized
in a way that hot inline candidates are in the same unit.
Of course this is bit backwards to the overall goal of making LTO to
simplify .h files.

Honza