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
