[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080427181411.GA31667@infradead.org>
Date: Sun, 27 Apr 2008 14:14:12 -0400
From: Christoph Hellwig <hch@...radead.org>
To: Sam Ravnborg <sam@...nborg.org>
Cc: Christoph Hellwig <hch@...radead.org>,
Adrian Bunk <bunk@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux arch <linux-arch@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH] prepare kconfig inline optimization for all
architectures
On Sun, Apr 27, 2008 at 08:09:57PM +0200, Sam Ravnborg wrote:
> With the config option we pass the inline hint to gcc (if enabled).
> So with the config option we have the possibility to pass a _hint_ to
> gcc about inlining.
>
> Before the config option there were no difference between
> static int alwyas_inline foo() {}
> and
> static int inline foo() {}
>
> With the config option we now have a situation where they actually
> differ as they should do (assuming gcc > 4.x).
As Linus mentioned the hint doesn't make any sense because gcc will
get it wrong anyway. In fact when you look at kernel code it tends
to inline the everything and the kitchensink as long as there's just
one caller and this bloat the stack but doesn't inline where it needs
to. Better don't try to mess with that and do it explicit.
> So you say that it is safe to assume all places where we really need
> always_inline are annotedted such - and we do not need a simple
> config option that the user can uncheck.
I don't say it is that, it certainly isn't on powerpc and probably most
other architectures right now, because only x86 got the fixup so far.
But making it a user-visible option instead of an architecture opt
in/out selection doesn't make any sense.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists