This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C compile time
> > As I described in the other mail, we can do the inlining decisions first
> > and the do the top-down inlining based on these. It is possible to get
> > upper estimate of function body after the inlining, on the other hand we
> > can probably do significantly better if we were doing inlining
> > step-by-step and optimizing the intermediate results so we have better
> > idea about how far the inlined version simplify.
>
> Yes, deciding when to do that is one of the tricky bits.
Simple heuristics can be to do this only when the resulting body
estimate is small so the function will remain inline candidate and the
resulting function will actually be considered for inlining many times
(as we do always inline functions called once).
This should imit the overall growth caused by the decision pass by the
number of nontrivial functions (having more than one calee) *
small_function_threshold that should be enought.
>
> > In unit-at-a-time I already do have analysis to recognize these cases.
> > How hard would be to make current tree-inline.c to not do the copy and
> > modify trees in place instead?
>
> I'm not sure.
>
> In theory what you suggest is possible, but it might be pretty tricky.
That what I was affraid of :(
>
> (You'd have to walk the whole tree and fix up any DECL_CONTEXT entries;
> I'm not sure what else might or might not need to change.)
>
> If eliminated SAVE_EXPR in favor of real variables everywhere, this
> might be easier. In other words, doing this in GIMPLE might be easier.
> But, unfortunately, you may want to inline before that point...
Why do we want inline before gimplifing?
Honza
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com