On Fri, Jan 09, 2009 at 08:46:20AM -0800, Dirk Hohndel wrote: > On Fri, 09 Jan 2009 08:34:57 -0800 > "H. Peter Anvin" <hpa@xxxxxxxxx> wrote: > > > > As far as naming is concerned, gcc effectively supports four levels, > > which *currently* map onto macros as follows: > > > > __always_inline Inline unconditionally > > inline Inlining hint > > <nothing> Standard heuristics > > noinline Uninline unconditionally > > > > A lot of noise is being made about the naming of the levels (and I > > personally believe we should have a different annotation for "inline > > unconditionally for correctness" and "inline unconditionally for > > performance", as a documentation issue), but those are the four we > > get. > > Does gcc actually follow the "promise"? If that's the case (and if it's > considered a bug when it doesn't), then we can get what Linus wants by > annotating EVERY function with either __always_inline or noinline. There's also one alternative: gcc's inlining algorithms are extensibly tunable with --param. We might be able to find a set of numbers that make it roughly work like we want it by default. Disadvantage: the whole thing will be compiler version dependent so we might need to have different numbers for different compiler versions and it will be an area that will need constant maintenance in the future. I'm not sure that's really a good path to walk down to. Also cc Honza in case he has comments (you might want to review more of the thread in the archives) -Andi -- ak@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
