Memory footprint/compile time explosion caused by the tree inliner

[Daniel Berlin]

On Thu, 17 Apr 2003, Dale Johannesen wrote:

> On Thursday, April 17, 2003, at 04:38  PM, Mike Stump wrote:
> > On Thursday, April 17, 2003, at 03:15 PM, Eric Botcazou wrote:
> >>  The
> >> time is mostly (85%) spent in the scheduler but the regression is
> >> caused by
> >> the tree inliner.
> >
> > It would be nice if the scheduler works with very large functions.  It
> > is ok to miss some of the edges, as long as the creamy center is nice.
>
> Last time I looked, the scheduler bottleneck was free_deps().  People
> have
> obviously already worked on speeding it up and I didn't see anything
> else
> promising; good luck.

Err, if it's really free_deps, then it's a matter of changing data
structures a bit.
If you used a special INSN_LIST/EXPR_LIST that was
1. GC allocated
2. Not marked by GC by being in an INSN (IE needs some other root to be
traversed marked)
3. Added a root in the scheduler that pointed to them, that was null'ed
out by free_deps

Then you would be able to simply collect every so often in the scheduler,
and free_deps would just be

root = NULL;


Or something like this.

Anything similar (IE arena allocating/obstack allocating) requires not
using the standard INSN_LIST/EXPR_LIST as well.
At least, i'm assuming other places use INSN_LIST/EXPR_LIST and expect
them to live over passes, or else it's safe to just modify
INSN_LIST/EXPR_LIST themselves.