On Fri, 14 Mar 2003, Matt Austern wrote:
On Friday, March 14, 2003, at 03:11 AM, Olivier Galibert wrote:
On Thu, Mar 13, 2003 at 04:40:38PM -0800, Eric Christopher wrote:
Something that is given as implementation specific can occasionally be
worked out among different compiler vendors, you stand a better chance
of getting the behavior into the language than to get that type of
coordination.
Funnily enough, for every other decent compiler out there, "inline"
means "inline if you can".
That's not true. Most compilers that I know of use heuristics to decide
whether or not to do inlining, and will ignore a request to inline an
excessively large function. Some compilers ignore the inline keyword
altogether, and use information gained from interprocedural analysis
do decide whether to do inlining. (Note: I'm not suggesting that gcc
go down that route, at least not yet. That sort of thing only makes
sense for a state of the art optimizing compiler, which gcc isn't.)
We can give users the choice. In the past, "-finline-functions" let the
compiler decide, and the "inline" keyword let the user decide. There is
no other possible use for the an "inline" keyword that makes any sense -
if the compiler can randomly decide that it will override it, it is no
longer serving a useful purpose [*] (which is exactly what happened to the
"register" keyword). So, we apparently noticed that we just got rid of
a useful feature and decided to add the feature again under a different
name ("__attribute__((always_inline))"). All we've accomplished is that
a large body of existing code will have to be updated to use the attribute,
for no apparent gain and with increased obfuscation in user code.
[ I think the language semantics arguments (etc. the setjmp example) are
strawmen: there's a simple solution, we can just say the inline keyword
doesn't affect validity of code; code using "inline" is valid iff it would
be valid without using "inline". ]
My suggestion: lose always_inline (probably too late for that), don't add
obey_inline, just restore functionality to what we had in the past. Which
we can do by just taking the obey_inline patch and trimming it down a
little.
Bernd
[*] Predictability is the key as far as I'm concerned. I know that we
didn't inline _every_ function marked with "inline", but we usually had a
good reason for it (e.g. "the function uses alloca") and warned for it.
As it stands now, it might as well depend on the phase of the moon, and
that makes it worse than useless.