Re: Memory footprint/compile time explosion caused by the tree inliner

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> Possible solutions, don't allow more than 15x growth in caller, don't
> allow caller to grow past 1,000 stmts.

Yes, I think a global cap is really needed.

> 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.

According to Vlad, there is no hope, the scheduler is at least O(n^2).

> Suggestion:
>
> 	if (sum_insns > MAX_INLINE_INSNS * 128
>
> 	    || sum_insns > 15 * (currfn_insn - (id ? id->inlined_stmts : 0)))

Hmm... I think this formula doesn't make sense since currfn_insn is the insns 
count of the function to be inlined, not of the function from which we are 
inlining. The whole heuristics is purely local, there is no global control 
at all.

> Better, make the 15 a parameter.  Try values 2-20 on real C++ code,
> benchmark the benefit v compile time, set value near knee.  I think the
> relative cap is better than an absolute cap, as large bodied functions
> (aka C), the limit will be higher, and in small bodied functions, the
> limit will be lower.

Yes, a relative cap is probably better.

> Thanks for tacking this down, wanna try testing out the code above and
> find a reasonable constant and submit it?

I'll investigate the problem but I'll be on vacation for the next 10 days 
with no computer at hand.

-- 
Eric Botcazou