On Dec 10, 2012, at 5:07 PM, David Laight wrote:
> 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.
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
