Re: attribute((leafify)) for 3.4

[Jan Hubicka <hubicka at ucw dot cz>]

> On Mon, 27 Oct 2003, Richard Guenther wrote:
> 
> > Hi!
> >
> > I tried to move attribute((leafify)) from 3.3 to 3.4 (see attached patch).
> > I do this by marking nodes in the callgraph down from leafify functions as
> > disregarding their inlining limits (which results in them being treated as
> > always_inline functions). Unfortunately this doesnt really inline all of
> > the callees of a leaf function as the patch for 3.3 does.
> >
> > Still this patch improves performance of generated code by 25% (compared
> > to the 3.4 value without leafify, 3.3 with leafify improves by 45%).
> >
> > Any ideas how to improve the patch? Especially how to reduce "false"
> > forced inlining of nodes into non-leafify functions? I know we're in stage
> > 3, so adding a new attribute is out of question, but I really like to have
> > this feature locally, and preferrably as good as the 3.3 version.
> 
> I tried to look at how inlining is actually performed to maybe get
> topological sorting for the inline candidates right without marking the
> edges as to be inlined and at inlining toggle inlining by a flag checking
> for attribute((leafify)) here. But I'm totally lost looking at the
> expand_call_inline() function. Also the cgraph_decide_inlining*()
> functions are not easily to understand.

I have some cleanups for these, but I am not sure whether it is good
idea to commit that in stage3.  I will probably put it into tree-ssa
branch.

The idea is to make some better defined API for the code managing
inlining flag, so the inlining decision logic don't need to be dealt
with in the inlining heuristics itself.

I was holding these patches because of the incremental inlining patch I
wanted to go in first.  It went in last week, but I didn't had chance to
do the rest yet (too many bugfixing and similar high priority stuff)
> 
> My idea was to add a maybe_inline_call flag to the cgraph edges and use
> this the same as the inline_call flag at topological sorting time, but
> treat it the same as inline_call flag only if assembling a function decl
> with attribute((leafify)) set.

I actually was playing with similar idea too.  It is quite easy to get
it basically working by modifying inline_call_p candidate to know
whether it is called for leafifed function or not.

However there are several places where inline_call flag matters.  It is
used to determine whether off-line version of function is needed on
several places, also it is used for code size growth estimation code.
All this would significantly get confused by doing non-transitive
inlining.

It seems to me that we should try to get this done by assigning separate
cgraph nodes to the function clones.  It would result in better global
dataflow sollutions too and would simplify logic of several other
places.

What about giving up the attribute for 3.4 (we are in feature freeze
already anyway) and doing so on tree-ssa?  I will prepare the cleanups
during next week so we can make progress on it.

Honza
> 
> Does this sound possible? Where would be the "obvious" places I'm going to
> miss something?
> 
> Thanks for any help with this,
> 
> Richard.
> 
> --
> Richard Guenther <richard dot guenther at uni-tuebingen dot de>
> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/