This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: question about inlining
On December 8, 2017 6:50:17 PM GMT+01:00, Martin Sebor <msebor@gmail.com> wrote:
>On 12/08/2017 12:00 AM, Richard Biener wrote:
>> On December 8, 2017 4:26:05 AM GMT+01:00, Martin Sebor
><msebor@gmail.com> wrote:
>>> On 12/06/2017 11:45 PM, Richard Biener wrote:
>>>> On December 7, 2017 2:15:53 AM GMT+01:00, Martin Sebor
>>> <msebor@gmail.com> wrote:
>>>>> On 12/06/2017 12:11 PM, Richard Biener wrote:
>>>>>> On December 6, 2017 6:38:11 PM GMT+01:00, Martin Sebor
>>>>> <msebor@gmail.com> wrote:
>>>>>>> While testing a libstdc++ patch that relies on inlining to
>>>>>>> expose a GCC limitation I noticed that the same member function
>>>>>>> of a class template is inlined into one function in the test but
>>>>>>> not into the other, even though it is inlined into each if each
>>>>>>> is compiled separately (i.e., in a file on its own).
>>>>>>>
>>>>>>> I wasn't aware that inlining decisions made in one function
>could
>>>>>>> affect those in another, or in the whole file. Is that
>expected?
>>>>>>> And if yes, what's the rationale?
>>>>>>>
>>>>>>> Here's a simplified test case. When compiled with -O2 or -O3
>>>>>>> and either just -DFOO or just -DBAR, the call to
>vector::resize()
>>>>>>> and all the functions called from it, including (crucially)
>>>>>>> vector::_M_default_append, are inlined. But when compiled with
>>>>>>> -DFOO -DBAR _M_default_append is not inlined. With a somewhat
>>>>>>> more involved test case I've also seen the first call inlined
>>>>>>> but not the second, which was also surprising to me.
>>>>>>
>>>>>> There are unit and function growth limits that can be hit.
>>>>>
>>>>> I see, thank you for reminding me.
>>>>>
>>>>> Nothing brings the implications into sharp focus like two
>virtually
>>>>> identical functions optimized differently as a result of exceeding
>>>>> some size limit. It would make perfect sense to me if I were
>using
>>>>> -Os but I can't help but wonder how useful this heuristic is at
>-O3.
>>>>
>>>> Well. The inlining process is basically inlining functions sorted
>by
>>> priority until the limits are hit (or nothing is profitable
>anymore).
>>> Without such limit we'd blow size through the roof.
>>>
>>> I understand why it's done. What I'm wondering is if the logic
>>> that controls it or the selected per-translation unit limits do,
>>> in fact, yield optimal results at all optimization levels, and
>>
>> Well - the limits are set in a way to limit code size growth. In that
>sense they are 'optimal' in case the set growth percentage is what you
>want...
>>
>>> if they do, what it means for users and how they structure their
>>> source code.
>>>
>>> It obviously surprised me to have the compiler optimize a simple,
>>> trivial function on its own one way only to then disable the same
>>> optimization when another equivalent function was added to the
>>> file. It rendered my test ineffective and I only found out by
>>> accident. I suspect others would find this effect surprising as
>>> well, and not in a good way. If the inlining algorithm is tuned
>>> to deliver optimal results at all optimization levels (but even
>>> if it isn't) then its effects seem worth pointing out in the
>>> manual. What advice should we give to users when it comes to
>>> inlining? I'm thinking of something that might go in section
>>> An Inline Function is As Fast As a Macro:
>>> https://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Inline.html
>>> (unless there's a better place for it).
>>
>> Do not make tiny translation units. There are several knobs to work
>around the fact that if the compiler only sees one TU estimating growth
>of the whole program is hard. This is why we do so much better with
>LTO.
>
>Okay, that's actually the opposite of what I was thinking at
>first (one function per TU) but it makes sense for C++ where
>large translation units are the norm. It also makes sense
>for C projects already structured to define one function per
>TU. Where it breaks down is in projects that do something
>in between. Let me see if I can put a sentence or two
>together to add that to the inlining page and also mention
>LTO.
Well, don't do small TUs because we will grow them too much in fact...
The various parameters are documented but eventually an overall description is missing. Otoh I don't think we have something like an optimization guide?
>It might also make sense to mention this on the GCC testing
>Wiki as a pitfall when writing test cases because those are
>almost invariably small.
>
>Martin