From: Alexandre Oliva <aoliva@redhat.com>
To: ncunningham@linuxmail.org
Cc: Andi Kleen <ak@muc.de>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: GCC 3.4 and broken inlining.
Date: 10 Jul 2004 18:33:40 -0300 [thread overview]
Message-ID: <orr7rjo8cr.fsf@livre.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: <1089349003.4861.17.camel@nigel-laptop.wpcb.org.au>
On Jul 9, 2004, Nigel Cunningham <ncunningham@linuxmail.org> wrote:
> I do think that functions being declared inline when they can't be
> inlined is wrong
The problem is not when they can or cannot be inlined. The inline
keyword has nothing to do with that. It's a hint to the compiler,
that means that inlining the function is likely to be profitable.
But, like the `register' keyword, it's just a hint. And, unlike the
`register' keyword, it doesn't make certain operations on objects
marked with it ill-formed (e.g., you can't take the address of an
register variable, but you can take the address of an inline
function).
The issue with inlining that makes it important for the compiler to
have something to say on the decision is that several aspects of the
profit from expanding the function inline is often machine-dependent.
It depends on the ABI (calling conventions), on how slow call
instructions are, on how important instruction cache hits are, etc.
Sure enough, GCC doesn't take all of this into account, so its
heuristics sometimes get it wrong. But it's getting better.
Meanwhile, you should probably distinguish between must-inline,
should-inline, may-inline, should-not-inline and must-not-inline
functions. Attribute always_inline covers the must-inline case; the
inline keyword covers the may-inline'case. The absence of the inline
keyword implies `should-not-inline', and attribute noinline covers
must-not-inline. should-inline can't be expressed today, and if
may-inline doesn't get the desired effect, you may feel tempted to
abuse always_inline, but I suggest you to do so using a different
macro, such that, if GCC ever introduces a new attribute that's a
stronger hint to inlining that doesn't error out if it can't be done,
you can easily switch to it.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
next prev parent reply other threads:[~2004-07-10 21:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2fFzK-3Zz-23@gated-at.bofh.it>
[not found] ` <2fG2F-4qK-3@gated-at.bofh.it>
[not found] ` <2fG2G-4qK-9@gated-at.bofh.it>
[not found] ` <2fPfF-2Dv-21@gated-at.bofh.it>
[not found] ` <2fPfF-2Dv-19@gated-at.bofh.it>
2004-07-09 4:51 ` Andi Kleen
2004-07-09 4:56 ` Nigel Cunningham
2004-07-09 5:46 ` Andi Kleen
2004-07-09 9:43 ` Michael Buesch
2004-07-09 10:23 ` Paweł Sikora
2004-07-10 21:33 ` Alexandre Oliva [this message]
2004-07-11 5:52 ` Andi Kleen
2004-07-14 3:00 ` Alexandre Oliva
2004-07-09 18:40 ` Adrian Bunk
2004-07-09 21:54 ` Andi Kleen
2004-07-09 22:17 ` Adrian Bunk
2004-07-10 4:50 ` Andi Kleen
2004-07-10 21:25 ` Alexandre Oliva
2004-07-11 5:53 ` Andi Kleen
2004-07-11 6:55 ` Andrew Morton
2004-07-11 8:26 ` Andi Kleen
2004-07-11 8:32 ` Andrew Morton
2004-07-11 9:08 ` Andi Kleen
2004-07-11 11:50 ` Adrian Bunk
2004-07-11 13:01 ` Arnd Bergmann
2004-07-13 1:02 ` [updated 2.6 patch] #define inline as __attribute__((always_inline)) also for gcc >= 3.4 Adrian Bunk
[not found] <fa.hnj36kg.4no2jk@ifi.uio.no>
[not found] ` <fa.gktbdsg.1n4em8o@ifi.uio.no>
2004-07-10 3:12 ` GCC 3.4 and broken inlining Robert Hancock
[not found] <2fVEt-6Vy-11@gated-at.bofh.it>
[not found] ` <2fVO5-79H-3@gated-at.bofh.it>
[not found] ` <2fWqQ-7uv-19@gated-at.bofh.it>
[not found] ` <2g0b6-1Cf-23@gated-at.bofh.it>
2004-07-09 10:04 ` Andi Kleen
2004-07-08 11:46 Nigel Cunningham
2004-07-08 12:07 ` Jakub Jelinek
2004-07-08 12:11 ` Nigel Cunningham
[not found] ` <200407090036.39323.vda@port.imtp.ilyichevsk.odessa.ua>
2004-07-08 22:00 ` Nigel Cunningham
2004-07-08 22:41 ` Zan Lynx
2004-07-09 6:54 ` Arjan van de Ven
2004-07-10 21:20 ` Alexandre Oliva
2004-07-08 20:52 ` Adrian Bunk
2004-07-08 21:09 ` Arjan van de Ven
2004-07-08 22:08 ` Nigel Cunningham
2004-07-08 22:25 ` Adrian Bunk
2004-07-08 22:37 ` Nigel Cunningham
2004-07-09 6:24 ` Arjan van de Ven
2004-07-10 1:21 ` Adrian Bunk
2004-07-10 2:30 ` William Lee Irwin III
2004-07-13 22:19 ` Timothy Miller
2004-07-10 6:31 ` Arjan van de Ven
2004-07-10 21:17 ` Alexandre Oliva
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=orr7rjo8cr.fsf@livre.redhat.lsd.ic.unicamp.br \
--to=aoliva@redhat.com \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@linuxmail.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
all inboxes | Powered by JetHome®