From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14923 invoked by alias); 23 Oct 2012 14:13:16 -0000 Received: (qmail 14198 invoked by uid 55); 23 Oct 2012 14:12:45 -0000 From: "hubicka at ucw dot cz" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/54966] Does LTO requires a larger inline-unit-growth? Date: Tue, 23 Oct 2012 14:13:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at ucw dot cz X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg02057.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54966 --- Comment #6 from Jan Hubicka 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