Re: [PATCH] Clean up early inliner

[Richard Guenther <rguenther at suse dot de>]

On Mon, 12 Apr 2010, Jan Hubicka wrote:

> > 
> > The latter sounds like what they should do anyways - inline limit
> > functions disregarding inline limits.  What else? ;)
> 
> Yep, it is a better variant given that we decided to make the small function
> inliner consider all alwaysinlines.
> 
> As a consequence alwaysinlines will also end up being fed to recursive inlining
> I think.  So be sure that something like the following:
> 
> static inline
> __attribute__ ((always_inline))
> bomb ()
> { 
>   while (q())
>     bomb(),
>     bomb(),
>     bomb(),
>     bomb(),
>     bomb(),
>     bomb();
> }
> void
> t()
> { 
>   bomb ();
> }
> 
> won't blow up the compiler :) (it almost does now ;))

Does it?  Not for me (neither with nor without the patch).
It of course sorrry()s out.

Anyway, I'll shortcut this as well to save some compile-time.

Note that for the testcase above it doesn't make sense to
inline bomb() into t at all, still we do it.  To improve
the situation here we'd indeed need to compute cgraph SCCs
and simply use the heuristic to not increase SCC size by
inlining (thus, not inline A into B if they are in different
non-singleton SCCs).

Richard.