Re: KNF and the C preprocessor

[<Paul_Koning%Dell.com@localhost>]

On Dec 10, 2012, at 5:07 PM, David Laight wrote:

> On Mon, Dec 10, 2012 at 09:26:08PM +0000, Paul_Koning%Dell.com@localhost 
> 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.

I wouldn't describe it that way.  And I don't think the GCC documentation does. 
 It does talk about heuristic inlining, but that's for the -O3 feature of 
inlining stuff that's *not* marked, based on heuristics that it might be useful.
> 
> 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).

There are switches that control what gets inlined.  In particular, there is one 
that says not to inline things (other than called-once things) that are bigger 
than X.  If things are not getting inlined when expected, that is one possible 
cause.

        paul