RFC: Inlines, LTO and GCC

[Andrew MacLeod]

On 09/10/2013 04:44 AM, Richard Biener wrote:
> On Tue, Sep 10, 2013 at 10:11 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote:
>>> This last point is crucial.  I haven't looked at the code in question,
>>> but one point to check is how the functions are called.  If they are
>>> often called with constant values, then they may be very much simplified
>>> due to constant propagation.  Secondly, if a function is inlined, the
>>> compiler has full knowledge of the effects of the function "call" and
>>> can thus optimise better (keeping data in registers over the "call",
>>> shuffling around loads and stores, etc.).  Finally, if the functions are
>>> called in loops or other time-critical code, it can be worth spending
>>> more code section space for a faster result (but sometimes smaller code
>>> is faster due to caches, branch prediction buffers, etc.).
>>>
>>> The ideal situation is that LTO figures this out for you, and the code
>> At least until LTO keeps to end up with unusable or hardly usable debug
>> info, effectively requiring LTO for good compiler performance is a
>> non-starter.  And, the inliner we have is not dumb, if it sees an inline
>> function, but it is too large, it will usually not inline it.
>> So, rather than counting the lines of inline functions in headers, IMHO it
>> is better to look at inliner's decisions about those functions, if it
>> never inlines them, then supposedly moving them out of line is reasonable.
> I mostly agree.  Though please also factor in IPA-CP - the reason that
> get_addr_base_and_unit_offset_1 is inline is that it receives a callback
> which in all call-sites is constant or NULL and optimizing that function
> is cruical (it will be usually called once in each TU and thus either inlined
> or cloned for IPA-CP).
>
> Also the operand iterators are very important to optimize, so outlining
> them is a non-starter.
>
> There isn't much code I'd expect we want to put back into .c files instead
> given that we now use C++ I'd expect more code to be moved into header
> files because of the use of templates.
>
> That's the way of life with C++ - you got what you wanted ;)
>
>
:-) Gonna be a lot of little inlines that is for sure.

I think its probably more worthwhile to focus on getting functions into 
appropriate places than trying to make decisions about what should or 
shouldn't be inlined at this point.