public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Matt Austern <austern@apple.com>
To: Tolga Dalman <ates100@web.de>
Cc: gcc@gcc.gnu.org
Subject: Re: Inlining (was: GCC 3.3 release criteria)
Date: Tue, 25 Feb 2003 18:01:00 -0000	[thread overview]
Message-ID: <F0B5E2D8-48EA-11D7-A0F6-00039390D9E0@apple.com> (raw)
In-Reply-To: <20030225042011.1864b3ed.ates100@web.de>

On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote:

>> We definitely don't want -fobey-inline to be the default: usually it's
>> better for the compiler to treat the inline keyword as a hint, and to
>> use its own heuristics to decide when to accept the hint.  But there 
>> are
>> cases, as you've found, when a flag like this is useful.
>>
>
> this confuses me a bit. i always thought, that the "inline" keyword 
> would
> in any case force inlining, except for the -fno-inline flag activated.
> IMHO, the compiler should always obey user inlining, because the 
> compiler
> should trust the programmer when he uses an optional feature (such as 
> inline).
> for me, the question evolves: what does happen in -Os optimization? i 
> suppose,
> there isn't done any inline at all, not even explicitely "inline" 
> marked
> functions, no?

Some programmers have the expectation that the compiler will always 
inline
everything that's marked inline.  Other programmers very definitely do 
not
expect that, and write code where 'inline' is treated merely as a hint 
to the
compiler: marking a function 'inline' means you're telling the compiler 
that
you won't mind if it chooses to inline the function.

(Inline-as-hint is what the C++ Standard says, for what it's worth.  I 
don't know
the C99 standard as well.)

Empirically, treating 'inline' as a directive rather than a hint will 
make a lot
of programs much worse.  This isn't conjecture.  We did the measurement 
at
Apple.  -fobey-inline is occasionally useful, but making it the default 
would be
disastrous.

In the end I expect that more and more compilers will choose to ignore 
the
'inline' keyword entirely.  They'll treat it the same way as 
'register', and for
the same reason: a sufficiently clever optimizer has more information 
than
the programmer does, and can do a better job of knowing which functions
should be inlined.  Some optimizers are already good enough so that's 
true.
Our optimizer isn't (yet), but that's where we eventually want to be.

			--Matt

  reply	other threads:[~2003-02-25 17:59 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200302232354.SAA19348@caip.rutgers.edu.suse.lists.egcs-patches>
2003-02-24 20:33 ` GCC 3.3 release criteria Andi Kleen
2003-02-24 20:37   ` Jakub Jelinek
2003-02-24 20:47   ` Daniel Jacobowitz
2003-02-24 21:30     ` Franz Sirl
2003-02-25 10:34       ` Richard Earnshaw
2003-02-25 10:57         ` Steven Bosscher
2003-02-25 11:18           ` Richard Earnshaw
2003-02-25 11:32             ` Gabriel Dos Reis
2003-02-25 12:30               ` Richard Earnshaw
2003-02-25 12:36                 ` Gabriel Dos Reis
2003-02-25 14:04                   ` Richard Earnshaw
2003-02-25 14:17                     ` Richard Earnshaw
2003-02-25 18:48                       ` Joseph S. Myers
2003-02-25 14:42                     ` Gabriel Dos Reis
2003-02-25 15:28                       ` Richard Earnshaw
2003-02-25 15:42                         ` Fergus Henderson
2003-03-01 13:16             ` Bernd Schmidt
2003-03-01 13:59               ` Richard Earnshaw
2003-02-25 11:30           ` Gabriel Dos Reis
2003-02-25 11:55             ` Lars Segerlund
2003-02-25 19:31               ` tm_gccmail
2003-02-25 20:58                 ` Michael Hayes
2003-02-25 21:09                   ` Matt Austern
2003-02-25 22:01                     ` tm_gccmail
2003-02-26  0:23                       ` Richard Henderson
2003-02-25 22:07                     ` Stuart Hastings
2003-02-26  0:11                       ` Richard Henderson
2003-02-25 22:22                     ` Christoph Hellwig
2003-02-25 22:35                       ` Matt Austern
2003-02-25 22:58                         ` Michel LESPINASSE
2003-02-25 23:09                           ` Daniel Jacobowitz
2003-02-25 23:43                             ` Matt Austern
2003-02-25 23:45                               ` Dale Johannesen
2003-02-26 11:45                               ` Mattias Engdegård
2003-02-25 12:10         ` Kean Johnston
2003-02-25 13:51           ` Andreas Schwab
2003-02-25 12:13         ` Franz Sirl
2003-02-26  1:14           ` Richard Henderson
2003-02-24 23:56   ` Kaveh R. Ghazi
2003-02-25  0:32     ` Andi Kleen
2003-02-25  0:54   ` Inlining (was: GCC 3.3 release criteria) Matt Austern
2003-02-25  6:43     ` Tolga Dalman
2003-02-25 18:01       ` Matt Austern [this message]
2003-02-25 19:51         ` Tolga Dalman
2003-02-25 20:47         ` Michel LESPINASSE
2003-02-25 21:22         ` Timothy J. Wood
2003-02-26  4:29         ` Gabriel Dos Reis
2003-02-26 10:10           ` Olivier Galibert
2003-02-26 11:05             ` Gabriel Dos Reis
2003-02-27 15:26               ` Allan Sandfeld
2003-02-25  8:09     ` Steven Bosscher
2003-02-25  8:31     ` Andi Kleen
     [not found] <F0B5E2D8-48EA-11D7-A0F6-00039390D9E0@apple.com.suse.lists.egcs>
     [not found] ` <m3wujn90fs.fsf@uniton.integrable-solutions.net.suse.lists.egcs>
     [not found]   ` <20030226044029.A1163@kerberos.ncsl.nist.gov.suse.lists.egcs>
     [not found]     ` <m3isv78gp7.fsf@uniton.integrable-solutions.net.suse.lists.egcs>
2003-02-26 11:47       ` Andi Kleen
2003-02-26 11:53         ` Gabriel Dos Reis
2003-02-26 13:44           ` Andi Kleen
2003-02-26 13:58             ` Gabriel Dos Reis
2003-02-26 21:50               ` Matt Austern
2003-02-26 22:04                 ` Andi Kleen

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=F0B5E2D8-48EA-11D7-A0F6-00039390D9E0@apple.com \
    --to=austern@apple.com \
    --cc=ates100@web.de \
    --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).