This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: -fobey-inline (was Re: gcc and inlining)
- From: dewar at gnat dot com (Robert Dewar)
- To: echristo at redhat dot com, galibert at pobox dot com
- Cc: Richard dot Earnshaw at arm dot com, aph at redhat dot com, dewar at gnat dot com,gcc at gcc dot gnu dot org
- Date: Fri, 14 Mar 2003 12:33:33 -0500 (EST)
- Subject: 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.