This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]