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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html