[PATH] PR/49139 fix always_inline failures diagnostics

[Jan Hubicka]

> >>
> >> whenever you take the address of an always_inline function
> >> (because then you can confuse GCC by indirectly calling
> >> such function which we might inline dependent on optimization
> >> setting and which we might discover we didn't inline only
> >> dependent on optimization setting).Honza proposed to move
> >> the sorry()ing to when we feel the need to output the
> >> always_inline function, thus when it was not optimized away,
> >> but that would require us not preserving the body (do we?)
> >> with -fpreserve-inline-functions.

I don't think we can preserve them with -fpreserve-inline-functions because
the ssa intrincisc or functions calling va_arg_pack can not be expanded
when not inlined into proper context and having those in headers would imply
units using those headers to not compile with -fpreserve-inline-functions...

> 
> Honza - this conditional calling of optimize_inline_calls just if
> warn_inline is on is extra ugly.  Does it really save that much
> time to only conditionally run optimize_inline_calls?  If so
> we should re-write that function completely.

I don't think it is big deal to call that function each time.  It used
to be more expensive than it is now and the conditional was there just
because it was always there as far as I recall.

Honza