Re: attribute((leafify)) for 3.4

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

On Thu, 30 Oct 2003, Jan Hubicka wrote:

> > On Mon, 27 Oct 2003, Richard Guenther wrote:
> >
> > 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.

Well, I wouldnt need to have it in official 3.4, I just use a locally
patched gcc for my work. Btw. I tried the above (but obviously missed some
parts, as it doesnt work), see attached patch. I somehow circumvented most
of the problems you mention above, but it seems the functions are not
considered for inlining though cgraph_inline_p is modified to honour
the case of a callee of a leafify function (you didnt mean
cgraph_inline_p by inline_call_p?).

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Attachment: leafify-3.4-7
Description: leafify against 3.4