On Mon, Dec 10, 2012 at 09:26:08PM +0000, paul_kon...@dell.com wrote:
>
> On Dec 10, 2012, at 4:18 PM, David Young wrote:
>
> > On Mon, Dec 10, 2012 at 03:50:00PM -0500, Thor Lancelot Simon wrote:
> >> On Mon, Dec 10, 2012 at 02:28:28PM -0600, David Young wrote:
> >>> On Mon, Dec 10, 2012 at 07:37:14PM +0000, David Laight wrote:
> >>>
> >>>> a) #define macros tend to get optimised better.
> >>>
> >>> Better even than an __attribute__((always_inline)) function?
> >>
> >> I'd like to submit that neither are a good thing, because human
> >> beings are demonstrably quite bad at deciding when things should
> >> be inlined, particularly in terms of the cache effects of excessive
> >> inline use.
> >
> > I agree with that. However, occasionally I have found when I'm
> > optimizing the code based on actual evidence rather than hunches, and
> > the compiler is letting me down, always_inline was necessary.
> >
> > Dave
>
> Is that because of compiler bugs, or because the compiler was doing
> what it's supposed to be doing?
The compiler has some heuristics about what it is good to inline.
gcc tends to treat 'inline' as just a hint.
Genarally it likes inlining static functions that are only called once.
But it doesn't always do so - even when marked 'inline'
(marking them inline may have no effect).
Inlining leaf functions is particularly useful - as it removes a lot
of register pressure in the calling function.
If you can inline all calls - making a function a leaf one it is even better.
David
--
David Laight: da...@l8s.co.uk
