Re: Inlining (was: GCC 3.3 release criteria)

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> Olivier Galibert <galibert@pobox.com> writes:
> 
> | On Wed, Feb 26, 2003 at 04:37:43AM +0100, Gabriel Dos Reis wrote:
> | > Does -fobey-inline differ from __attribute__((always_inline))?
> | 
> | Yes, with -fobey-inline you only need to change the makefiles, not the
> | source.
> 
> Ah, I see what you mean.
> 
> This 
>      
>     -Dinline="__attribute__((always_inline)) inline"
> 
> (or something to that effect) was suggested earlier.  It just needs
> Makefile change.

The naive version of this often breaks because the shell does
funny things to the quotes, especially when the makefile uses a shell
script to call the compiler.

-include somefile.h 

and putting it in there works however.

Still this is a semantics change to older compilers, because it implicitely
forces -Werror -Winline

There are some functions that are not inlined for legitimate reasons and
these error out now.

-Andi

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Andi Kleen <ak@suse.de> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > Olivier Galibert <galibert@pobox.com> writes:
| > 
| > | On Wed, Feb 26, 2003 at 04:37:43AM +0100, Gabriel Dos Reis wrote:
| > | > Does -fobey-inline differ from __attribute__((always_inline))?
| > | 
| > | Yes, with -fobey-inline you only need to change the makefiles, not the
| > | source.
| > 
| > Ah, I see what you mean.
| > 
| > This 
| >      
| >     -Dinline="__attribute__((always_inline)) inline"
| > 
| > (or something to that effect) was suggested earlier.  It just needs
| > Makefile change.
| 
| The naive version of this often breaks because the shell does
| funny things to the quotes, especially when the makefile uses a shell
| script to call the compiler.
| 
| -include somefile.h 
| 
| and putting it in there works however.
| 
| Still this is a semantics change to older compilers, because it implicitely

Well, -fobey-inline is also  semantics change to older compilers.

| forces -Werror -Winline

Why so?

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

> | forces -Werror -Winline
> 
> Why so?

always_inline errors when the function cannot get inlined.

(the -Werror in my example only applies to the -Winline warning)

-Andi

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Andi Kleen <ak@suse.de> writes:

| > | forces -Werror -Winline
| > 
| > Why so?
| 
| always_inline errors when the function cannot get inlined.

Thanks for the education and your patience.

But then if -fobey-inline doesn't error then there is something about it?

Matt, what does happen when a function can't be inlined?

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Matt Austern]

On Wednesday, February 26, 2003, at 03:52 AM, Gabriel Dos Reis wrote:

> Andi Kleen <ak@suse.de> writes:
>
> | > | forces -Werror -Winline
> | >
> | > Why so?
> |
> | always_inline errors when the function cannot get inlined.
>
> Thanks for the education and your patience.
>
> But then if -fobey-inline doesn't error then there is something about 
> it?
>
> Matt, what does happen when a function can't be inlined?

Nothing special.  It inlines the function if possible; if not (e.g. if 
it's a
recursive call), then it just silently doesn't do the inlining.

			--matt

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

> >But then if -fobey-inline doesn't error then there is something about 
> >it?
> >
> >Matt, what does happen when a function can't be inlined?
> 
> Nothing special.  It inlines the function if possible; if not (e.g. if 
> it's a
> recursive call), then it just silently doesn't do the inlining.

That's exactly the semantics I want too. It would be nice if your patch
could be put into gcc 3.3

-Andi

Re: GCC 3.3 release criteria

[Andi Kleen]

"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

> <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>

gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
currently because the inlining algorithm is too broken. The Linux
kernel often assumes that functions marked "inline" get inlined and
when they aren't it results in linking errors. In a few rare cases
you also get silent miscompilation (this happened in the x86-64 port,
now fixed)

Only good workaround currently is -Dinline="__attribute__((always_inline))",
just using -finline-limit=hugenumber doesn't help.
 
Better would be likely to fix the inlining heuristics to honor the inline
keyword better.

-Andi

Inlining (was: GCC 3.3 release criteria)

[Matt Austern]

On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:

> "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>
>> <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
>
> gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> currently because the inlining algorithm is too broken. The Linux
> kernel often assumes that functions marked "inline" get inlined and
> when they aren't it results in linking errors. In a few rare cases
> you also get silent miscompilation (this happened in the x86-64 port,
> now fixed)

As it happens, Apple may be able to contribute a patch that does what
you're looking for.  We've got a local patch that adds a new command
line switch, -fobey-inline.   The switch does exactly what you think: 
the
compiler will inline every function that's marked 'inline' whenever it's
possible.  (There are still cases where it's not possible, of course, 
e.g.
if you mark a recursive function inline.)

We definitely don't want -fobey-inline to be the default: usually it's
better for the compiler to treat the inline keyword as a hint, and to
use its own heuristics to decide when to accept the hint.  But there are
cases, as you've found, when a flag like this is useful.

If Apple contributed the -fobey-inline patch, would people here be
interested in it?

			--Matt

Re: Inlining (was: GCC 3.3 release criteria)

[Tolga Dalman]

On Mon, 24 Feb 2003 16:32:17 -0800 Matt Austern <austern@apple.com> wrote:

> On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:
> 
> > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> >
> >> <tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> >
> > gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> > currently because the inlining algorithm is too broken. The Linux
> > kernel often assumes that functions marked "inline" get inlined and
> > when they aren't it results in linking errors. In a few rare cases
> > you also get silent miscompilation (this happened in the x86-64 port,
> > now fixed)
> 
> As it happens, Apple may be able to contribute a patch that does what
> you're looking for.  We've got a local patch that adds a new command
> line switch, -fobey-inline.   The switch does exactly what you think: 
> the
> compiler will inline every function that's marked 'inline' whenever it's
> possible.  (There are still cases where it's not possible, of course, 
> e.g.
> if you mark a recursive function inline.)
> 
> We definitely don't want -fobey-inline to be the default: usually it's
> better for the compiler to treat the inline keyword as a hint, and to
> use its own heuristics to decide when to accept the hint.  But there are
> cases, as you've found, when a flag like this is useful.
> 

this confuses me a bit. i always thought, that the "inline" keyword would
in any case force inlining, except for the -fno-inline flag activated. 
IMHO, the compiler should always obey user inlining, because the compiler 
should trust the programmer when he uses an optional feature (such as inline).
for me, the question evolves: what does happen in -Os optimization? i suppose, 
there isn't done any inline at all, not even explicitely "inline" marked
functions, no?

brg,
Tolga Dalman.

Re: Inlining (was: GCC 3.3 release criteria)

[Matt Austern]

On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote:

>> We definitely don't want -fobey-inline to be the default: usually it's
>> better for the compiler to treat the inline keyword as a hint, and to
>> use its own heuristics to decide when to accept the hint.  But there 
>> are
>> cases, as you've found, when a flag like this is useful.
>>
>
> this confuses me a bit. i always thought, that the "inline" keyword 
> would
> in any case force inlining, except for the -fno-inline flag activated.
> IMHO, the compiler should always obey user inlining, because the 
> compiler
> should trust the programmer when he uses an optional feature (such as 
> inline).
> for me, the question evolves: what does happen in -Os optimization? i 
> suppose,
> there isn't done any inline at all, not even explicitely "inline" 
> marked
> functions, no?

Some programmers have the expectation that the compiler will always 
inline
everything that's marked inline.  Other programmers very definitely do 
not
expect that, and write code where 'inline' is treated merely as a hint 
to the
compiler: marking a function 'inline' means you're telling the compiler 
that
you won't mind if it chooses to inline the function.

(Inline-as-hint is what the C++ Standard says, for what it's worth.  I 
don't know
the C99 standard as well.)

Empirically, treating 'inline' as a directive rather than a hint will 
make a lot
of programs much worse.  This isn't conjecture.  We did the measurement 
at
Apple.  -fobey-inline is occasionally useful, but making it the default 
would be
disastrous.

In the end I expect that more and more compilers will choose to ignore 
the
'inline' keyword entirely.  They'll treat it the same way as 
'register', and for
the same reason: a sufficiently clever optimizer has more information 
than
the programmer does, and can do a better job of knowing which functions
should be inlined.  Some optimizers are already good enough so that's 
true.
Our optimizer isn't (yet), but that's where we eventually want to be.

			--Matt

Re: Inlining (was: GCC 3.3 release criteria)

[Tolga Dalman]

On Tue, 25 Feb 2003 09:59:52 -0800 Matt Austern <austern@apple.com> wrote:

> On Monday, February 24, 2003, at 07:20 PM, Tolga Dalman wrote:
> 
> >> We definitely don't want -fobey-inline to be the default: usually it's
> >> better for the compiler to treat the inline keyword as a hint, and to
> >> use its own heuristics to decide when to accept the hint.  But there 
> >> are
> >> cases, as you've found, when a flag like this is useful.
> >>
> >
> > this confuses me a bit. i always thought, that the "inline" keyword 
> > would
> > in any case force inlining, except for the -fno-inline flag activated.
> > IMHO, the compiler should always obey user inlining, because the 
> > compiler
> > should trust the programmer when he uses an optional feature (such as 
> > inline).
> > for me, the question evolves: what does happen in -Os optimization? i 
> > suppose,
> > there isn't done any inline at all, not even explicitely "inline" 
> > marked
> > functions, no?
> 
> Some programmers have the expectation that the compiler will always 
> inline
> everything that's marked inline.  Other programmers very definitely do 
> not
> expect that, and write code where 'inline' is treated merely as a hint 
> to the
> compiler: marking a function 'inline' means you're telling the compiler 
> that
> you won't mind if it chooses to inline the function.
> 

yeah, but i'm not able to say "definitively: don't compile this function as
inlined one!", neither saying "inline" nor saying "don't inline" is then
possible.

> (Inline-as-hint is what the C++ Standard says, for what it's worth.  I 
> don't know
> the C99 standard as well.)
> 
> Empirically, treating 'inline' as a directive rather than a hint will 
> make a lot
> of programs much worse.  This isn't conjecture.  We did the measurement 
> at
> Apple.  -fobey-inline is occasionally useful, but making it the default 
> would be
> disastrous.
> 

i understand. IMHO, gcc _should_ deprecate the ISO-C qualifiers inline and
register then , since they are not usable in an appropriate way. doing so, gcc
could "educate" a programmer _not_ to use these keywords, even though they're
defined in the standard. 

> In the end I expect that more and more compilers will choose to ignore 
> the
> 'inline' keyword entirely.  They'll treat it the same way as 
> 'register', and for
> the same reason: a sufficiently clever optimizer has more information 
> than
> the programmer does, and can do a better job of knowing which functions
> should be inlined.  Some optimizers are already good enough so that's 
> true.
> Our optimizer isn't (yet), but that's where we eventually want to be.

but that's not the point: from my point of view as "user", i want to be able to
disable inlining entirely except for those functions i explicitely mark (via
-Os for example). or the other way round: i want to inline everything (with a
certain threshold of course), except for a few function that never should be
inlined. 
i believe, the standard inlining algorithms are very good, but gcc (rather the
standard itself) makes finetuning impossible. please correct me, if i was wrong.

brg, 
Tolga.

Re: Inlining (was: GCC 3.3 release criteria)

[Michel LESPINASSE]

On Tue, Feb 25, 2003 at 09:59:52AM -0800, Matt Austern wrote:

> Some programmers have the expectation that the compiler will always
> inline everything that's marked inline.  Other programmers very
> definitely do not expect that, and write code where 'inline' is
> treated merely as a hint to the compiler: marking a function
> 'inline' means you're telling the compiler that you won't mind if it
> chooses to inline the function.

In my experience, most C programmers expect inline to inline, while
C++ programmers dont.

> (Inline-as-hint is what the C++ Standard says, for what it's worth.
> I don't know the C99 standard as well.)

I'm not sure about C99 - my understanding is that the compiler is
allowed to ignore the inline keyword but most C programmers dont
expect it to.

> Empirically, treating 'inline' as a directive rather than a hint
> will make a lot of programs much worse.  This isn't conjecture.  We
> did the measurement at Apple.  -fobey-inline is occasionally useful,
> but making it the default would be disastrous.

Just to be clear: were these C programs or C++ ?

> In the end I expect that more and more compilers will choose to
> ignore the 'inline' keyword entirely.  They'll treat it the same way
> as 'register', and for the same reason: a sufficiently clever
> optimizer has more information than the programmer does, and can do
> a better job of knowing which functions should be inlined.  Some
> optimizers are already good enough so that's true.  Our optimizer
> isn't (yet), but that's where we eventually want to be.

I kinda agree that using 'register' today would be idiotic, as
compilers are pretty good at making that choice already. And I hope
gcc will get there with 'inline' as well eventually. But frankly,
today, gcc's inlining just sucks for C programmers. The inline keyword
is not as satisfying as a smart compiler heuristic might be, but it's
much nicer than what we have today.

Cheers,

-- 
Michel "Walken" LESPINASSE
Is this the best that god can do ? Then I'm not impressed.

Re: Inlining (was: GCC 3.3 release criteria)

[Timothy J. Wood]

On Tuesday, February 25, 2003, at 09:59  AM, Matt Austern wrote:
> Empirically, treating 'inline' as a directive rather than a hint will 
> make a lot
> of programs much worse.  This isn't conjecture.  We did the 
> measurement at
> Apple.  -fobey-inline is occasionally useful, but making it the 
> default would be
> disastrous.

   You could make -Winline be on by default instead.  This would let the 
compiler make the choice and would warn if an function was marked 
inline and the compiler disagreed with you (hopefully saying *why* it 
disagreed).

   This would help people get rid of extra 'inline' keywords and once 
that was done, they'd have a better chance of turning on -fobey-inline 
without terrible results (and presumably -fobey-inline would imply 
-Winline).

-tim

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

[...]

| Apple.  -fobey-inline is occasionally useful, but making it the
| default would be
| disastrous.

Does -fobey-inline differ from __attribute__((always_inline))?

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Olivier Galibert]

On Wed, Feb 26, 2003 at 04:37:43AM +0100, Gabriel Dos Reis wrote:
> Does -fobey-inline differ from __attribute__((always_inline))?

Yes, with -fobey-inline you only need to change the makefiles, not the
source.

  OG.

Re: Inlining (was: GCC 3.3 release criteria)

[Gabriel Dos Reis]

Olivier Galibert <galibert@pobox.com> writes:

| On Wed, Feb 26, 2003 at 04:37:43AM +0100, Gabriel Dos Reis wrote:
| > Does -fobey-inline differ from __attribute__((always_inline))?
| 
| Yes, with -fobey-inline you only need to change the makefiles, not the
| source.

Ah, I see what you mean.

This 
     
    -Dinline="__attribute__((always_inline)) inline"

(or something to that effect) was suggested earlier.  It just needs
Makefile change.

-- Gaby

Re: Inlining (was: GCC 3.3 release criteria)

[Allan Sandfeld]

On Wednesday 26 February 2003 11:44, Gabriel Dos Reis wrote:
> Olivier Galibert <galibert@pobox.com> writes:
> | On Wed, Feb 26, 2003 at 04:37:43AM +0100, Gabriel Dos Reis wrote:
> | > Does -fobey-inline differ from __attribute__((always_inline))?
> |
> | Yes, with -fobey-inline you only need to change the makefiles, not the
> | source.
>
> Ah, I see what you mean.
>
> This
>
>     -Dinline="__attribute__((always_inline)) inline"
>
> (or something to that effect) was suggested earlier.  It just needs
> Makefile change.
>
I guess this is what -fobey-inline does internally. The difference is that 
-fobey-inline makes immediate sense, and is a regular flag we can document in 
man and info. IOW people will know it's possible and use it.

`Allan

Re: Inlining (was: GCC 3.3 release criteria)

[Steven Bosscher]

Op di 25-02-2003, om 01:32 schreef Matt Austern:
> As it happens, Apple may be able to contribute a patch that does what
> you're looking for.  We've got a local patch that adds a new command
> line switch, -fobey-inline.   The switch does exactly what you think: 
> the
> compiler will inline every function that's marked 'inline' whenever it's
> possible.  (There are still cases where it's not possible, of course, 
> e.g.
> if you mark a recursive function inline.)
> 
> We definitely don't want -fobey-inline to be the default: usually it's
> better for the compiler to treat the inline keyword as a hint, and to
> use its own heuristics to decide when to accept the hint.  But there are
> cases, as you've found, when a flag like this is useful.

The compiler may be able to make better inlining decisionsm, but it
should IMHO never overrule the user.  So if the user says "inline this"
then the compiler should try really hard to do so, even if it thinks the
resulting code is worse than without inlining.

How about making "obey-inline" the default, with a flag to enable a
warning that would make the compiler complain if it thinks the function
shouldn't be inlined?

> If Apple contributed the -fobey-inline patch, would people here be
> interested in it?

Yes.

Greetz
Steven

Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen]

On Mon, Feb 24, 2003 at 04:32:17PM -0800, Matt Austern wrote:
> On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:
> 
> >"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
> >
> >><tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
> >
> >gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
> >currently because the inlining algorithm is too broken. The Linux
> >kernel often assumes that functions marked "inline" get inlined and
> >when they aren't it results in linking errors. In a few rare cases
> >you also get silent miscompilation (this happened in the x86-64 port,
> >now fixed)
> 
> As it happens, Apple may be able to contribute a patch that does what
> you're looking for.  We've got a local patch that adds a new command
> line switch, -fobey-inline.   The switch does exactly what you think: 
> the
> compiler will inline every function that's marked 'inline' whenever it's
> possible.  (There are still cases where it's not possible, of course, 
> e.g.
> if you mark a recursive function inline.)

Yes, that is why I don't like the -Dinline="__attribute__((always_inline)) inline"
way too much - there are a few valid reasons why inline functions marked
inline didn't get inlined and this define changes behaviour for them
by essentially forcing -Winline -Werror

> If Apple contributed the -fobey-inline patch, would people here be
> interested in it?

I would still prefer if inline was much stronger for C programs by default
(I realize that the situation is different for C++ where inline is used
much more frequently and in a different way), but failing that
-fobey-inline would be useful too. The problems seem to root in trying
to handle C and C++ with the same heuristics.

Preferably for 3.3 too then.

-Andi