Re: [tree-ssa] Fix function body estimation

[Jan Hubicka <hubicka at ucw dot cz>]

> > I see.  I have kind of GIMPLE version ready.  I see that currently all
> > frontends directly gimplieize instead of producing generic node.  Is
> > this the way it is supposed to work or we are going to use generic more
> > commonly in future?
> 
> gfortran produces GENERIC.  C and C++, AFAIU, produce GIMPLE because
> they were originally written produce SIMPLE -- there wasn't anything in
> between like GENERIC at the time.

OK,
stupid question how does GENERIC differ from langauge specific trees
when it still has language specific nodes?
> > There is deeper problem tought.
> > In general I think we ought to do some early optimization passes before
> > the function body size is estimated, so the functions probably should
> > get gimplified first.
> 
> The problem I see is that gimplification can sometimes produce quite a
> bit of obviously redundant code, so estimating the size of a gimplified
> function tree will probably be a bit pessimistic.  Not sure if that'll
> be a problem.

On the other hand the lower representation is, the more realistically we
estimate.  When gimplification produces redundant stuff, we will beleive
we are seeing it at generic level as well in case we get code size
estimated right.
> 
> (Another option could perhaps be (at some optimization levels, say -O3?)
> to partially or fully tree-optimize each function before any inlining
> takes place.  The tree-ssa passes are fast enough :)

Yes, that is what I would like to shoot for.
In fact we should be able to use profile esitmates for inlining.  That
means whtat we should gimplify whole compilation unit, build SSA, early
optimize, predict branch outcomes (via feedback or guessing), propagate
info into block frequencies and block frequencies into callgraph and the
decide inlining...
This is lots of fun to realize :)
> 
> >   Does it seem OK if I push gimplify call to
> > cgraph_analyze_function?  Do we need to re-gimplify after inlining or is
> > inliner already able to keep gimple gimple?
> 
> The tree inliner can keep functions in GIMPLE form.  See all the calls
> to keep_function_in_gimple_form() in tree-inline.c.
> At one point the tree-inliner even could _only_ inline GIMPLE and keep
> the function gimplified, but Jason changed that.  I don't recall why.

Jason, any idea?

Honza
> 
> Gr.
> Steven