public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Carlo Wood <carlo@alinoe.com>
To: gcc@gcc.gnu.org
Subject: issues with inlining
Date: Wed, 18 Dec 2002 18:32:00 -0000	[thread overview]
Message-ID: <20021219012212.GA26426@alinoe.com> (raw)

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 <carlo@alinoe.com>

             reply	other threads:[~2002-12-19  1:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-18 18:32 Carlo Wood [this message]
2003-01-09 21:40 ` Michel LESPINASSE
2003-01-09 21:50   ` Andrew Haley
2003-01-09 22:52     ` Michel LESPINASSE
2003-01-10  0:15       ` Carlo Wood
2003-01-19 19:16         ` Alexandre Oliva
2003-01-19 20:49           ` Diego Novillo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021219012212.GA26426@alinoe.com \
    --to=carlo@alinoe.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).