Messages in this thread | | | Date | Sun, 27 Apr 2008 20:09:57 +0200 | From | Sam Ravnborg <> | Subject | Re: [PATCH] prepare kconfig inline optimization for all architectures |
| |
On Sun, Apr 27, 2008 at 02:00:07PM -0400, Christoph Hellwig wrote: > On Sun, Apr 27, 2008 at 08:47:14PM +0300, Adrian Bunk wrote: > > What I want instead: > > - we continue to force the compiler to always inline with "inline" > > - we remove the inline's in .c files and make too big functions in > > headers out-of-line > > It doesn't matter whether we use inline or always_inline to force > inlining of a function, that's just syntactical sugar.
inline => the developer hints the compiler that it may be a good idea to inline this function
always_inline => the developer tell gcc that for some obscure reasons MUST always inline uses of this function
> What is rather > annoying is that with the config option we'd have something marked > inline without actually meaning it's inline. 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).
> And what's even worse > is that this is depending on a user-visible config option which is > entirely stupid. 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. Fine by me - I prefer the simpler solution.
Sam
| |