This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: attribute((leafify)) for 3.4
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>, gcc at gcc dot gnu dot org
- Date: Sat, 1 Nov 2003 12:46:49 +0100 (CET)
- Subject: Re: attribute((leafify)) for 3.4
- References: <20031031121709.GB12532@kam.mff.cuni.cz><Pine.LNX.4.44.0310311332290.1646-200000@bellatrix.tat.physik.uni-tuebingen.de><20031031155316.GE12532@kam.mff.cuni.cz>
On Fri, 31 Oct 2003, Jan Hubicka wrote:
> > On Fri, 31 Oct 2003, Jan Hubicka wrote:
> >
> > initialization up to avoid going endlessly through callgraph loops.
> > Recursive inlining seems to be prevented somehow at least for not-direct
>
> Ah, I see, there is still recursive inlining preventing code in
> tree-inline I wanted to remove after killing old heuristics code.
> OK, still you mark maybe_inline in cyclic way in the callgraph that will
> eventually bring you problems if you attempt to get right the code size
> estimation (BTW you should at least increase global_insns during
> leafifying or you will get the leafifed function inlined too many times)
I dont update the code size because we wont inline leafified functions
anyway, as documented (I clear edge.inline_call for them). I suspect the
code size estimates would be overly pessimistic anyway (thats the reason
for using leafify, otherwise the heuristics would work, too).
> > I won't submit this officially for 3.4, as I dont have a copyright
> > assignment yet and I suspect this would last too long to be accepted late
> > in stage 3 anyways. Also the concept of leafify needs some arguments.
> > Apart from this I think it is trivial for you to implement this
> > functionality after cleanup in 3.5, so I wont need to fiddle around with
> > copyright assignments.
>
> OK, I will try to get into this soon.
Thanks,
Richard.