> > Index: ipa-cp.c
> > ===================================================================
> > --- ipa-cp.c        (revision 221757)
> > +++ ipa-cp.c        (working copy)
> > @@ -811,6 +811,41 @@ set_all_contains_variable (struct ipcp_p
> >    return ret;
> >  }
> >  
> > +/* Worker of call_for_symbol_thunks_and_aliases, increment the integer DATA
> > +   points to by the number of callers to NODE.  */
> > +
> > +static bool
> > +count_callers (cgraph_node *node, void *data)
> > +{
> > +  int *caller_count = (int *) data;
> > +
> > +  for (cgraph_edge *cs = node->callers; cs; cs = cs->next_caller)
> > +    /* Local thunks can be handled transparently, but if the thunk can not
> > +       be optimized out, count it as a real use.  */
> > +    if (!cs->caller->thunk.thunk_p || !cs->caller->local.local)
> > +      ++*caller_count;
> 
> ...we don't recurse for local thunks and do not count their number of
> callers here.  I'm not sure if it can ever happen in practice but if
> we have a local function that is called multiple times but always
> through one particular local thunk, we should end with caller_count
> greater than one, and with this code we will not?  Such function
> certainly should not be considered called just once by the inliner.

Inliner won't inline to thunks at all currently, but you call the function
by for_symbol_thunks_and_aliases, so the recursion to thunks already happens
by this wrapper.
> 
> Similarly, if we ever have a local node with a non-local thunk (would
> that be legal and make sense?), then we should try not ending up with

We currently keep local falg in sync in between thunks and functions (otherwise
i386 calling convetions will break). But indeed we may add check here to avoid
dependency on this detail.

Honza
> caller_count == 1, because inliner will also never consider that
> function just called once.  So I'd suggest incrementing the caller by
> two instead in that case.
> 
> But maybe I just don't understand what "handled transparently" in the
> comment means.
> 
> Thanks for clearing this up,
> 
> Martin

Reply via email to