This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: question about inlining long call sequence

On Tue, Feb 12, 2019 at 6:16 PM Martin Jambor <> wrote:
> 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".  */
Thanks, assume it's below code collecting maximum code size limit
along call stack:

  while (true)
      info = inline_summaries->get (to);
      if (limit < info->self_size)
        limit = info->self_size;
      if (stack_size_limit < info->estimated_self_stack_size)
        stack_size_limit = info->estimated_self_stack_size;
      if (to->global.inlined_to)
        to = to->callers->caller;

Question is it only collects the maximum self_size of outer callers,
since we are inlining from outer function to inner, only check
self_size of caller means we can still get bloated size for some
cases? Or what piece of code I have missed?

Another question is in want_inline_small_function_p:

      /* Apply MAX_INLINE_INSNS_AUTO limit for functions not declared inline
         Upgrade it to MAX_INLINE_INSNS_SINGLE when hints suggests that
         inlining given function is very profitable.  */
      else if (!DECL_DECLARED_INLINE_P (callee->decl)
               && !big_speedup
               && !(hints & INLINE_HINT_known_hot)
               && growth >= ((hints & (INLINE_HINT_indirect_call
                                       | INLINE_HINT_loop_iterations
                                       | INLINE_HINT_array_index
                                       | INLINE_HINT_loop_stride))
                             ? MAX (MAX_INLINE_INSNS_AUTO,
                             : MAX_INLINE_INSNS_AUTO))
So for function not declared as inline, if it's considered as
known_hot, there will be no size restriction at all.  This looks like
an issue to me, given we do restrict size even for know_hot function
which is declared as inline:

      /* Apply MAX_INLINE_INSNS_SINGLE limit.  Do not do so when
         hints suggests that inlining given function is very profitable.  */
      else if (DECL_DECLARED_INLINE_P (callee->decl)
               && growth >= MAX_INLINE_INSNS_SINGLE
               && ((!big_speedup
                    && !(hints & (INLINE_HINT_indirect_call
                                  | INLINE_HINT_known_hot
                                  | INLINE_HINT_loop_iterations
                                  | INLINE_HINT_array_index
                                  | INLINE_HINT_loop_stride)))
                   || growth >= MAX_INLINE_INSNS_SINGLE * 16))

Again, this is on GCC6.

> Martin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]