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

[Bernd Schmidt <bernds at redhat dot com>]

On Thu, 13 Mar 2003, Richard Earnshaw wrote:

> > Richard Earnshaw writes:
> >  > > 
> >  > > -fobey-inline is more of a correctness issue than a performance issue
> >  > > for the people who need it.
> >  > 
> >  > No, it's a compile my buggy program issue.
> >  > 
> >  > There is no guarantee in the standard that an "inline" function will be 
> >  > inlined.
> > 
> > Yes, but there are places where being able to guarantee inlining are
> > very useful.  glibc has one in the shared library loader, and there
> > are places in a kernel where it is essential to inline (perhaps
> > because there is no stack) but people are forced to use macros if
> > inlining is not guaranteed.  macros are bad for a bunch of reasons,
> > not the least of which is type safety.
> > 
> 
> And we have an attribute (always_inline) for that case.  We don't need 
> another method as well.

always_inline is just extra clutter, either in the sources or in the Makefile.
In previous versions, if you wanted the compiler to make decisions for you,
you said -finline-functions.  If you wanted to be reasonably certain that
the compiler inlined a function, you said "inline" in the program file.
What we currently have is that "inline" has basically no meaning anymore
(just like "register"), and if you want sane behaviour, you need to add a
clumsy attribute.  This breaks existing programs; not in the sense of
causing them to fail to compile or work, but by causing severe performance
regressions.

It's the change in behaviour from previous versions that bothers me, and
this is the reason why I would like something like -fobey-inline as default.


Bernd