Re: [PATCH] Fix inlining of always_inline functions

[Jan Hubicka <hubicka at ucw dot cz>]

> 
> This fixes a testcase I produced reducing PR42632.  During
> early inlining we inline a non-always-inline function into
> an always-inline function.  This breaks inlining when
> being in a cycle and part of it is marked always-inline.
> 
> Note that inlining into an always-inline function incrementally
> is always bogus - this either pessimizes size of callers of
> the always-inline function or is premature as the function would
> be inlined into the caller of the always-inline function anyway.
> It might save some compile-time but I consider this unlikely
> and it does indeed break inlining in cycles as seen by the testcase.
> 
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> 
> Honza, any objections to this?

Well, I was always bit in favour of declaring always inline bad idea on
cyclic callgraphs, but I guess this will work too and won't cause much
of code quality issues (by disabling early inlining you also makes early
opt less effective and thus function calling always_inline functions
after inlining them will get bigger code size estimates in real
inliner).
But I guess these beasts are not common enough to matter.

Honza