Re: attribute((leafify)) for 3.4

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

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.

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.

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/