From: Robert Hancock <hancockr@shaw.ca>
To: Adrian Bunk <bunk@kernel.org>
Cc: Andreas Mohr <andi@lisas.de>, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] kernel/sched*: optimize inlining
Date: Sun, 11 May 2008 11:25:49 -0600 [thread overview]
Message-ID: <48272C1D.8020301@shaw.ca> (raw)
In-Reply-To: <fa.sBJgAJSNbPht40KbEGBXczzW3vQ@ifi.uio.no>
Adrian Bunk wrote:
> On Sun, May 11, 2008 at 01:18:20PM +0200, Andreas Mohr wrote:
>> [manual reply, no access to original content]
>>
>> Hi,
>>
>> rather NACKish here (from my minor side, that is, since there are no
>> useful explanations, and in the case of a lack of explanations no
>> backing numbers either which would have been helpful to resolve this ;).
>>
>> "x86: add optimized inlining"
>> (http://kerneltrap.org/mailarchive/git-commits-head/2008/4/26/1612644)
>> does not really say anything relevant to your patch, AFAICS.
>>
>> That one simply says that previously every inline was force-inlined (ugh),
>> which now gcc is allowed to properly decide by itself now. This, however,
>> does _NOT_ imply that it's now somehow fully sufficient for a perfect outcome
>> to simply remove all open-coded "inline"s.
>
> They both do the same - gcc is no longer forced to inline these
> functions.
>
> With either my patch or the "optimized inlining" it's 100% gcc's
> choice whether or not to inline functions marked as "inline" in
> kernel/sched* .
>
> If you didn't complain when "x86: add optimized inlining" got into
> Linus' tree you can't validly complain about my patch.
It's not really the same thing. Not forcing gcc to do the inlining where
it's marked is one thing, but removing the hint to inline the function
entirely is something else. In this case without the hint it clearly
makes the wrong decision, since there is no reason to not inline a
function that just calls another function.
GCC 4.3 is supposed to have some improvements in this area with
pre-inline optimization and early inlining, but older gcc versions may
still have this issue.
next parent reply other threads:[~2008-05-11 17:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.kBy7Kr77qTR+lDVDv4OKx7n5m1Y@ifi.uio.no>
[not found] ` <fa.8/KGOoB8CQ+uVBJXmUNHaIfXQSg@ifi.uio.no>
[not found] ` <fa.sBJgAJSNbPht40KbEGBXczzW3vQ@ifi.uio.no>
2008-05-11 17:25 ` Robert Hancock [this message]
2008-05-11 9:21 [2.6 patch] kernel/sched*: optimize inlining Adrian Bunk
2008-05-11 11:18 ` Andreas Mohr
2008-05-11 12:52 ` Adrian Bunk
2008-05-11 17:22 ` Ray Lee
2008-05-11 17:52 ` Sam Ravnborg
2008-05-11 18:49 ` Adrian Bunk
2008-05-11 19:42 ` Sam Ravnborg
2008-05-11 20:00 ` Adrian Bunk
2008-05-11 20:38 ` Sam Ravnborg
2008-05-11 21:19 ` Adrian Bunk
2008-05-11 21:44 ` Sam Ravnborg
2008-05-11 22:11 ` Adrian Bunk
2008-05-12 6:57 ` Sam Ravnborg
2008-05-12 7:45 ` Adrian Bunk
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=48272C1D.8020301@shaw.ca \
--to=hancockr@shaw.ca \
--cc=andi@lisas.de \
--cc=bunk@kernel.org \
--cc=linux-kernel@vger.kernel.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