From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10501 invoked by alias); 24 Apr 2002 22:24:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 10494 invoked from network); 24 Apr 2002 22:24:17 -0000 Received: from unknown (HELO www.dberlin.org) (151.204.251.216) by 209.249.29.67 with SMTP; 24 Apr 2002 22:24:17 -0000 Received: from localhost (unknown [127.0.0.1]) by www.dberlin.org (Postfix) with ESMTP id 3C3E510667F2; Wed, 24 Apr 2002 18:24:05 -0400 (EDT) Date: Wed, 24 Apr 2002 16:31:00 -0000 From: Daniel Berlin To: Kurt Garloff Cc: gcc@gcc.gnu.org Subject: Re: inliner in gcc-3.1 In-Reply-To: <20020424132314.B27120@gum01m.etpnet.phys.tue.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg01269.txt.bz2 On Wed, 24 Apr 2002, Kurt Garloff wrote: > Hi, > > I was browsing the gcc ML archives (I'm not subscribed) and found > that the inliner may still not be tuned optimally in gcc-3.1. > http://gcc.gnu.org/ml/gcc/2002-04/msg01168.html > The problem seems to be mainly with C++ functions, where you want small > accessor functions to be reliably inlined and where the inliner heuristics > sometimes fails. > > I've done some work on this before and got a patch of mine merged (between > 3.0.1 and 3.0.3) that fixed the heuristics which lead to ridicolous compile > time resource requirements (gcc-3.0.0) resp. ridicolous performance > (gcc-3.0.1) according to my own and Gerard Pfeifer's benchmarks. See > http://www.garloff.de/kurt/freesoft/gcc/ > > To give a very short summary: Before gcc-3.0, some accounting for the > inlining was introduced to prevent huge functions to be inlined due to > recursive inlining. Unfortunately, inlining starts at the root > of the call tree, so in the end, the leaves would not be inlined any more > despite being the most performance critical very often. > This was fixed with a simplistic patch that does just reduce the acceptable > size for inlining for single functions by a factor of two and -- after > reaching the (full) limit by recursion -- cut it further down by another > factor of two. (This is what I refer to as v1 of my inliner patch.) > That patch fixed the most serious problems and got merged. > > Later I did some more fine tuning (patches v2,v3) and did use some linear > function to limit acceptable inlinable sizes for single functions. This > seems somewhat saner. It did only give slightly better results in > benchmarks. > > I'd like to add a few comments again: > * I was expecting to find the AST inliner in gcc-3.1. > I do believe it's more sane starting to inline from the leaves of > a call tree than from the root, so I would have expected that approach > (if tuned well) to win all benchmarks. Do you have anything to back up that statement? Are there any commercial compilers that do it that way? Intel's, for instance, has only a few differences from what we have. This is what they do: Start at root. At most 2000 intel intermediate code statements are inlined into the caller. 1. Functions with the following substrings in their name are not inlined: (various names signifying aborts, exits, fails, and warns, as well as alloca) 2. Focus on callers containing loops, and callees containing loops. (This is probably most important). 3. Don't inline functions > a certain number of statements. They default to 230 Intel intermediate code statements. 4. Stop when you detect direct recursion. 5. All functions < a certain number of statements are inlined. (This is because it's cheaper to inline than do the arg setup). For IA32, the number of statements is 7, for IA64, it's 15.