From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4285 invoked by alias); 19 Dec 2002 01:22:28 -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 4277 invoked from network); 19 Dec 2002 01:22:27 -0000 Received: from unknown (HELO mail.alinoe.com) (24.132.80.10) by 209.249.29.67 with SMTP; 19 Dec 2002 01:22:27 -0000 Received: (qmail 26475 invoked by uid 500); 19 Dec 2002 01:22:12 -0000 Date: Wed, 18 Dec 2002 18:32:00 -0000 From: Carlo Wood To: gcc@gcc.gnu.org Subject: issues with inlining Message-ID: <20021219012212.GA26426@alinoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2002-12/txt/msg01173.txt.bz2 Imho there are serious problems with inlining and gcc 3.x. As most of you know, I am not a compiler hacker, but extensively using the compiler for every day development of C++ libraries and recently I've laid my eyes on optimization issues (needing fast code and all). The inlining problems exist of functions not being inlined that should have been inlined, and others getting inlined while they would better not have been inlined. The following problems have been spotted: 1) -Winline doesn't give me a warning when a function is not inlined, even while I am using the inline keyword for it. 2) g++ 3.2.1 seems to totally ignore the inline keyword and do as it pleases when being used with -O3. Unfortunately, I know better than the compiler what should be inlined - so, ignoring the inline keyword and inlining other functions results in much slower code. 3) Apparently gcc is still inlining "top down", meaning that when a() calls b() which calls c() which calls d(), then b() is inlined into a(), c() is inlined into d() and when then the function becomes too big, it stops. THIS IS HORRIBLE!!! This *definitely* needs to be changed into that d() is inlined into c(), and if the function isn't getting too big, then c() into b() etc. 4) The instruction limit that can be set with -finline-limit seems to count instructions before optimization... This means that I need to give a limit of 8000 instructions before everything is inlined - although after optimization hardly anything is left (maybe 50 to 100 instructions, way below the default 600 threshold). By the time I get my inner functions inlined this way, EVERYTHING is inlined (I get one big function call of 120,000 instructions :/ (after compiling 60 minutes)). The reason for this functionality failure is imho related to templates: With C++ templates it happens that more and more code is available at the same time, unlike for C code. Code with lots and lots of templates (like my code) exists often for 95% of header files. That makes it increasingly important for the compiler to start inlining "bottom up", and to honour 'inline' keywords by giving them a high priority. -- Carlo Wood