This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: Inlines, LTO and GCC
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: David Brown <david at westcontrol dot com>, Jakub Jelinek <jakub at redhat dot com>, Jeff Law <law at redhat dot com>, Andrew MacLeod <amacleod at redhat dot com>, GCC <gcc at gcc dot gnu dot org>, Diego Novillo <dnovillo at google dot com>
- Date: Tue, 10 Sep 2013 12:24:56 +0200
- Subject: Re: RFC: Inlines, LTO and GCC
- Authentication-results: sourceware.org; auth=none
- References: <522E3374 dot 4000509 at redhat dot com> <522E87A4 dot 7060904 at redhat dot com> <522ED2EC dot 9090807 at westcontrol dot com> <20130910081111 dot GS1817 at tucnak dot redhat dot com> <522ED471 dot 9000702 at westcontrol dot com> <20130910090646 dot GA5522 at kam dot mff dot cuni dot cz>
On Tue, Sep 10, 2013 at 11:06 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> On 10/09/13 10:11, Jakub Jelinek 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.
>> >
>> > Jakub
>> >
>>
>> That should be easy enough with "-Winline", I think.
>
> What i also do from time to time is to do LTO profiledbootstrap and look into
> inline dump. Then you have inlining ordered by pretty realistic measure of
> benefits, so you see what matters and what not.
>
> Inliner knows that constant callbacks are good to inline and will bump up
> its limits.
>
> One problem is that we do have those functions as static inlines, so they ends
> up duplicated, with C++ we may consider moving them to comdat.
But then inlining / cloning is no longer cheap, no? And will be
disabled at -O2?
Richard.
> Honza
>>
>> David