Re: Inlining and estimate_num_insns

[Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>]

Jan Hubicka wrote:
> > Or have different inlining heuristics for C++.
>
>
> I tend to thing that common heuristics smart enought to catch C++
> abstraction should do fine for both.  Inlining is hitting us before each
> release, now imagine twice as many arugments here!
>
> The only problem with common heuristics I see is that in C the "inline"
> keyword is very strong hint basically meaning "I use language extension
> because I really want to inline it", while in C++ it is "maybe I want to
> inline it, but maybe I just put it to header for fun".  We might want to
> distinguish these in the case we fail to deal with them in common
> miserably.

I think the frontends could just talk differently to the middle-end 
here.  F.i. I'd like dropping the current max-inline-insns-single limit
altogether and rely on the function/unit size growth limits.  The C
frontend could then operate as it did before, while for C++ it would
probably worth it to consider making -finline-functions default and
ignoring the "inline" keyword altogether (maybe with some exceptions).

Richard.