On Thu, 2009-01-08 at 19:33 +0100, Ingo Molnar wrote:
> * Linus Torvalds wrote:
> >
> > Ingo - I think we need to remove that crap again. Because gcc gets the
> > inlining horribly horribly wrong. As usual.
>
> Apparently it messes up with asm()s: it doesnt know the contents of the
> asm()
On Thu, 2009-01-08 at 17:44 -0800, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> >>
> >> We might still try the second or third options, as i think we shouldnt go
> >> back into the business of managing the inline attributes of ~100,000
> >> kernel fu
On Fri, 2009-01-09 at 22:34 +0100, Ingo Molnar wrote:
> The naming problem remains though:
>
> - Perhaps we could introduce a name for the first category: __must_inline?
> __should_inline? Not because it wouldnt mean 'always', but because it is
> 'always inline' for another reason than the c
On Fri, 2009-01-09 at 13:50 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Harvey Harrison wrote:
> >
> > __needs_inline? That would imply that it's for correctness reasons.
>
> .. but the point is, we have _thousands_ of inlines, and do you know which
&
On Fri, 2009-01-09 at 14:09 -0800, Linus Torvalds wrote:
> We have a few users of "__inline", but not very many. We can leave them
> alone, or just convert them to __inline__ or inline.
Actually I sent out a series of patches which mostly went in 2.6.27-28
timeframe, that's why there's a lot few
On Fri, 2009-01-09 at 14:09 -0800, Linus Torvalds wrote:
> Actually, the nice part about "inline_hint" would be that then we could
> have some nice config option like
>
> #ifdef CONFIG_FULL_CALL_TRACE
>#define inline_hint noinline
> #elif defined(CONFIG_TRUST_COMPILER)
>#define inline
On Sat, 2009-01-10 at 02:01 +0100, Ingo Molnar wrote:
> * Linus Torvalds wrote:
> - Headers could probably go back to 'extern inline' again. At not small
>expense - we just finished moving to 'static inline'. We'd need to
>guarantee a library instantiation for every header include file
