Re: -fobey-inline (was Re: gcc and inlining)

[Richard Earnshaw <rearnsha at arm dot com>]

> > Remember, inline was _added_ to the standard because it was considered
> > useful by the users.  It's not legacy like register, it's a recent
> > addition, not even 4 years old.  Unfortunately, because of the as-is
> > rule, the standard can't actually express what it's supposed to mean.
> 
> The trouble is that inlining can mean two quite different things:
> 
> 1. Efficiency is important for calling this function. if it will speed things up,
> then please generate inline code. But only do this if it really will speed things
> up. I certainly don't want you to slow things down to meet this request.
> 
> 2. I have some reason you don't know about for inlining, and at the level of actual
> semantic effects of my program, I absolutely need inlining, even if it slows things
> down.
> 
> The Inline in the Ada and C standards seems more in category 1 to me, that's certainly
> true for Ada, which is why we added pragma Inline_Always for the second case. I think
> the situation in the C standard is similar, and a mechanism for enforcing inlining
> seems reasonable, although I think the argument for doing it with a local attribute
> seems stronger than having a compiler switch.
> 
> The compiler switch seems to be in more in category 1 than 2 above, and if needed
> seems to reflect that the compiler is not doing a good job of obeying the intent
> of the inline keyword. Seems better to fix this directly than add a switch to me.
> 

FWIW I agree with all of the above.  Particularly with respect to 
addressing the current inadequacies of the current inlining heuristics.

My concerns with respect to the inline_always attribute are to do with 
testing and how we should show that we've inlined things correctly 
(according to the way in which we deem inlining to be done in those corner 
cases).  As with many GCC extensions, we've added a feature without really 
considering the impact it has on the rest of the implementation.

R.