This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: question about inlining long call sequence
- From: Martin Jambor <mjambor at suse dot cz>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Cc: Jan Hubicka <jh at suse dot cz>
- Date: Tue, 12 Feb 2019 11:15:58 +0100
- Subject: Re: question about inlining long call sequence
- References: <CAHFci2-5F0_30Afp6XTAa3MDsN_DvA7bE2rBUDCmXM8+3oQnWw@mail.gmail.com>
On Tue, Feb 12 2019, Bin.Cheng wrote:
> Hi,
> When reading inlining code in GCC, I wonder if we have size heuristics
> to limit inlining long call sequence? For example, for call sequence
> A -> B -> C -> D -> ... -> X -> Y -> Z
> if each function call grows size by a very small amount, inlining Z
> all the way up to the outermost function could result in a big
> function which may hurt icache. Is this case handled in inliner? if
> yes, which code handles this? Thanks in advance.
>
> BTW, I am using GCC 6, not sure if trunk has different behavior.
I believe it is done in caller_growth_limits() in ipa-inline.c in both
trunk and GCC 6. The following comment in the function might shed a bit
more light on the behavior regarding big functions:
/* Look for function e->caller is inlined to. While doing
so work out the largest function body on the way. As
described above, we want to base our function growth
limits based on that. Not on the self size of the
outer function, not on the self size of inline code
we immediately inline to. This is the most relaxed
interpretation of the rule "do not grow large functions
too much in order to prevent compiler from exploding". */
HTH
Martin