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

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

[Robert Dewar]

> There are already compilers that do this.  (State of the art "SPEC 
> warrior" compilers, of course.)  gcc isn't one of them, and I agree 
> that gcc is unlikely to get all of these features any time soon, but 
> this really is production technology, not magical wishful thinking.

I would need to see more than a vague claim to believe that a compiler
can do a good job of implicit inlining without hints.

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

[Robert Dewar]

> Yes, I suppose it does, but it's less than elegant, and it's patronizing
> the user.  Especially in 'C', when people use "inline" they usually mean
> "inline".  Again, for C++ things may be different.

If you really meant that then you would want it to be a fatal error if
the compiler could not inline the function. I doubt many people want that.
I think they say inline to tell the compiler to make calls faster if
possible. 

There is a big difference between

inline this to speed it up, but if you can't OK (the standards' view
of inline)

and

inline or else the program is wrong, and fail if you can't inline it, 
because I am inlining it for semantic reasons that are outside the
scope of the standard.

Both mechanisms are useful, and should be present, and are. Why should it
be "patronizing" for the compiler to take the view of inline that is
taken by the standard.

Now if you are complaining that the compiler is too reluctant to inline,
that's a perfectly acceptable complaint, but it is a complaint about
optimization, not about correct implementation.

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

[Robert Dewar]

> I agree with that.  But that is not an argument to ignore the inline
> implied by in-class function definition:  That is part of common C++
> styles of writing programs.

Well it might be. if typically this implicit inlining causes programs to
slow down by excessive inlining, then the compiler is probably choosing
wrong defaults.

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

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > I agree with that.  But that is not an argument to ignore the inline
| > implied by in-class function definition:  That is part of common C++
| > styles of writing programs.
| 
| Well it might be. if typically this implicit inlining causes programs to
| slow down by excessive inlining, then the compiler is probably choosing
| wrong defaults.

Then, the same is true for "inline" specified for a function defined
out-of-class.  Which meets something that has been said earlier about
"inline" in C++. 

In fact, it is unaccurate to speak of implicit inlining for in-class
defined functions.  

We should be speaking of "implicit inlining" when the function
is defined *out-of-line* and the compiler thinks it knows better.
Or else, we'll create confusion (if we hadn't already succeeded ;-) 

-- Gaby

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

[Robert Dewar]

> That would be a disaster on STL-like code where function-object's
> operator() are commonly defined in the enclosing class.  I can't see
> any compeling reason why we should introduce that artificial distinction

I think there is an argument for a differentiation here. If a programmer
specifies inline, I think the compiler should be more ready to inline it.
In my experience, the compiler does too much inlining at -O3, and often
slows things down, so perhaps the automatic threshhold should be reduced,
but I don't think that is a good reason for reducing the threshhold for
an explicit inline. I am not ready to agree with people who think that
inline must always be obeyed, but I do think the compiler should go to
extra efforts to follow the (hopefully informed) hints from the user.


If one had infinite knowledge, the threshhold would depend on how often
the function is called. The compiler doesn't know that, so it can't make
the threshhold depend on this. But if there is an explicit inline, it is
reasonably taken as a hint that the frequency will be significant, so it
makes sense to have a higher thresshhold.

As for "disaster" on STL, that seems a bit overheated. Obviously you want
to set the thressholds to prevent disaster :-)

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

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > That would be a disaster on STL-like code where function-object's
| > operator() are commonly defined in the enclosing class.  I can't see
| > any compeling reason why we should introduce that artificial distinction
| 
| I think there is an argument for a differentiation here. If a programmer
| specifies inline, I think the compiler should be more ready to inline it.

And if the programmer defines the function in the class, then the
compiler should inline it also.  Have a look at the C++ STL-like
codes out there.  Putting the threasold lesser than if the function
were explicitly marked inline won't help nobody.

A distinction from C here is that there is more than one ways in C++ to
say "inline".

| In my experience, the compiler does too much inlining at -O3, and often
| slows things down, so perhaps the automatic threshhold should be reduced,
| but I don't think that is a good reason for reducing the threshhold for
| an explicit inline. I am not ready to agree with people who think that
| inline must always be obeyed, but I do think the compiler should go to
| extra efforts to follow the (hopefully informed) hints from the user.

I agree with that.  But that is not an argument to ignore the inline
implied by in-class function definition:  That is part of common C++
styles of writing programs.

-- Gaby

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

[Robert Dewar]

> I am well aware that the standard states that "inline" is advisory, 
> but in a high-quality implementation this should be taken to just cover
> the cases where inlining the call is not possible or is extremely difficult.
> If the compiler can honor the user's request without jumping through
> too many hoops, it should do so.

A corollary of this is that you still should not *count* on inline
if it is necessary for correct semantics (in your framework, not the
standards). In this case the attribute should be used.

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

[Robert Dewar]

> Hmm, I tried to make a point that there is no such thing as "smart
> enough", only "smart enough for where it's tuned to be smart".  Really,
> I'd love to see really a smart inlining decision algorithm, but in the
> end a compiler will always just be guessing.


Actually for the general case of compilers getting smart enough, there
is a point at which the compiler becomes "smart enough", and that is when
in the most typical case, the compiler can do a better job than the
programmer. At this stage, that criterion is pretty much met for
register allocation, and we don't see people arguing that it is horrible
for the compiler to override the intentions of the preogrammer etc etc.

For the inlining case, it is indeed rather dubious that this criterion
can ever be met. Too much information is required, and too much stuff
has to be analyzed.

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

[Tim Josling]

> 
> On Sat, 15 Mar 2003, Robert Dewar wrote:
> 
> Let me remind you that we are discussing the effects of a change in
> behaviour of our C compiler.  What Ada programmers do or don't do may be
> influenced by the behaviour of Ada compilers and might therefore not be
> entirely relevant.
> 

Correct. My old copy of the manual states that inline 'directs'
the compiler to inline the function.

More broadly, the C philosophy is that in C we allow the programmer to make mistakes,
on the basis that if they wanted to program in modula-2 and have mother decide everything for them
they would have done so.

Mostly, the compiler may make the right decision, but sometimes it does not.
For those cases the programmer should be able to override. It is not just about efficiency,
but also the size of the stack etc, all sorts of things the compiler may not know.

Tim Josling

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

[Robert Dewar]

> In the future, I think that the compiler should have a better idea about 
> what should be inlined than the programmer.  Therefore, in the long run 
> GCC should ignore the inline keyword.


Seems unlikely! This would require full interprocedural interunit analysis
as well as frequency data. I think this is in the wishful thinking depratment.

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

[Matt Austern]

On Sunday, March 16, 2003, at 08:38  PM, Robert Dewar wrote:

>> In the future, I think that the compiler should have a better idea 
>> about
>> what should be inlined than the programmer.  Therefore, in the long 
>> run
>> GCC should ignore the inline keyword.
>
>
> Seems unlikely! This would require full interprocedural interunit 
> analysis
> as well as frequency data. I think this is in the wishful thinking 
> depratment.

There are already compilers that do this.  (State of the art "SPEC 
warrior" compilers, of course.)  gcc isn't one of them, and I agree 
that gcc is unlikely to get all of these features any time soon, but 
this really is production technology, not magical wishful thinking.

			--Matt

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

[Robert Dewar]

> You've been arguing that the compiler will be smart enough to decide on
> a case-by-case basis whether inlining is profitable.  To make such an
> informed decision, you surely need information about function sizes and
> execution frequencies, among several other things.  If this information
> is available, then a mere hint becomes redundant [*] since you can deduce
> the necessary conditions algorithmically.  OTOH, if such information is
> not available, then the compiler really has no business second-guessing
> the user.

I have argued nothing of the kind, please reread what I have written. What
I have said is that the compiler may have very good reasons in specific
cases which result in a decision not to inline a given function. In fact
you agree with this:

> within reason - I don't strongly object to not inlining
> functions that call alloca, for example

What makes you think that I disagree and expect this to be done
without reason?

> OTOH, if such information is
> not available, then the compiler really has no business second-guessing
> the user.

A clear case to second guess in the absence of inline always, is a case
in which inlining is known  by the compiler to result in slower code
than not inlining.

or one in which it might be possible to inline, but it is just too much of
a pain in the neck to do so (the alloca case is in this category I think).

GNAT has an option to warn if a function is not inlined when it is requested
to be inlined, I think this is a useful (optional) warning.

> Let me remind you that we are discussing the effects of a change in
> behaviour of our C compiler.  What Ada programmers do or don't do may be
> influenced by the behaviour of Ada compilers and might therefore not be
> entirely relevant.

I see no reason to think the Ada and C experiences should be different here,
other than that the Ada community has 20 years experience with this feature.
The intention and language in the relevant standards is essentially 
identical in my view. If you think there is a big difference here, I think
the burden of proof is on you to show that.

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

[Bernd Schmidt]

On Sun, 16 Mar 2003, Robert Dewar wrote:

> > You've been arguing that the compiler will be smart enough to decide on
> > a case-by-case basis whether inlining is profitable.  To make such an
> > informed decision, you surely need information about function sizes and
> > execution frequencies, among several other things.  If this information
> > is available, then a mere hint becomes redundant [*] since you can deduce
> > the necessary conditions algorithmically.  OTOH, if such information is
> > not available, then the compiler really has no business second-guessing
> > the user.
> 
> I have argued nothing of the kind, please reread what I have written. What
> I have said is that the compiler may have very good reasons in specific
> cases which result in a decision not to inline a given function. In fact
> you agree with this:
> 
> > within reason - I don't strongly object to not inlining
> > functions that call alloca, for example
> 
> What makes you think that I disagree and expect this to be done
> without reason?

Ok, maybe it wasn't clear what you are arguing for, or maybe I'm just dense.
Please spell it out for me - which kinds of reasons do you consider valid?

As far as I'm concerned, anything that can be documented clearly and
predictably (and preferrably does not significantly differ from established
behaviour in older versions of gcc) is fine.  "The function calls alloca"
is OK as an exception, "the compiler knows it will be slower with inline" is
not well-defined enough.

Even in some exceptional cases (like the alloca one) it may be preferrable
to actually perform inlining and warn the user about potential drawbacks if
"-Wall" is specified.  Otherwise you still need an extra always_inline
construct.


Bernd

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

[Robert Dewar]

Bernd said

> > Now the compiler should react to this by actually doing the inlining if
> > indeed doing so can reasonbly be expected to improve execution time.
> 
> IMO this problem is AI-complete.


You missed the extreme importance of the word "reasonably". Generally
I would say this is like presumption in the law. If a programmer says
inline, the presumption is that inlining makes sense. Only if the
compiler has some very good reason for ignoring it, based on real
knowledge, should it be ignored. Otherwise reasonable behavior is to
believe the programmer. In Ada we find some cases which cause trouble
with inlining, in particular exception handlers can be problematical
in some cases.

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

[Robert Dewar]

> Paraphrased, this is equivalent to "I really don't know what's going on here,
> please make a decision for me".  We have support for this, it's called
> "-finline-functions".  For trivial situations like the one you describe, the
> compiler can usually make a good guess.

No, not at all, the decision to inline is almost always additionally 
informed by the knowledge that the function is called frequently, so
that inlining is worth while.

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

[Robert Dewar]

> Well, you'd assume the person who adds "inline" has done measurements or
> looked at the generated assembly.

I think you would be entirely wrong. Certainly in Ada, I can promise you
that (this is looking at 20 years of extensive experience with the use
of pragma Inline) most Ada programmers don't know enough to look at the
assembly language, and very few have done measurements. Actually the task
of doing measurements on a function by function basis is virtually
impossible, since the choices interact, so if you have K functions
that are possible candidates you would have to do 2**K measurements.

Even programmers who do know assembly language really well (I am one, I have
written hundreds of thousands of lines of commercially delivered assembly)
find it harder and harder to look at an assembly listing and have a good
idea of how fast things will run. The behavior of modern processors with
multiple pipelines where dozens of instructions can be in-flight and
branch prediction algorithms are both complex and critical, can be extremely
difficult to understand accurately. The old days when each instruction
took bla time and you added bla+bla+... to get the execution time for
a sequence of instructions are long long gone.

In practice the decision to use pragma Inline is based most typically
on an assumption that the function is small, because the source is
small and simple, and a knowledge that it is called frequently.

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

[Bernd Schmidt]

On Sat, 15 Mar 2003, Robert Dewar wrote:

> > Well, you'd assume the person who adds "inline" has done measurements or
> > looked at the generated assembly.
> 
> I think you would be entirely wrong. Certainly in Ada, I can promise you
> that (this is looking at 20 years of extensive experience with the use
> of pragma Inline) most Ada programmers don't know enough to look at the
> assembly language, and very few have done measurements.

Let me remind you that we are discussing the effects of a change in
behaviour of our C compiler.  What Ada programmers do or don't do may be
influenced by the behaviour of Ada compilers and might therefore not be
entirely relevant.

And yes, you can shoot yourself in the foot by adding inline to the wrong
function.  However, unlike a heuristic inside a compiler, a human can
recognize, fix, and learn from a mistake.

It almost seems like this is turning into a question of interface design -
one philosophy ("nothing wrong with 'rm -rf /', let's do it.") vs. another
("Do you really want to empty the trash can?").  My idea of a useful
program is one that lets people who know what they are doing get on with
it.  If they don't have a clue - not our problem; garbage in, garbage out.

> Actually the task
> of doing measurements on a function by function basis is virtually
> impossible, since the choices interact, so if you have K functions
> that are possible candidates you would have to do 2**K measurements.

This kind of difficulty applies as well if you let the compiler make the
decision.  What makes you think it can do a better job?

> In practice the decision to use pragma Inline is based most typically
> on an assumption that the function is small, because the source is
> small and simple, and a knowledge that it is called frequently.

You've been arguing that the compiler will be smart enough to decide on
a case-by-case basis whether inlining is profitable.  To make such an
informed decision, you surely need information about function sizes and
execution frequencies, among several other things.  If this information
is available, then a mere hint becomes redundant [*] since you can deduce
the necessary conditions algorithmically.  OTOH, if such information is
not available, then the compiler really has no business second-guessing
the user.
In either case the only sane meaning for the "inline" keyword is to
always inline (within reason - I don't strongly object to not inlining
functions that call alloca, for example).  The alternative is, in the
first case, to have no effect, and in the second case, to have a random
effect - neither is useful.

So, our choice is whether we turn "inline" into an effective no-op and
replace its functionality with "always_inline" (causing performance
regressions and clutter in existing code), or whether we go back to our
previous behaviour which is expected by user code and in which "inline"
actually had a meaning.


Bernd

[*] Like "register".

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

[Robert Dewar]

> On the other hand, inlining a function can create great opportunities for
> constant folding.  This is the point where gcc is currently very weak
> because it bases its heuristics on the unfolded size of the inline
> function.

Good point, and sometimes you write an inlined function knowing that
it will collapse when inlined, and this is a case where you really
do know better than the compiler.

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

[Robert Dewar]

> Sure.  The programmer had better know that if he's marking things
> inline.

Think what you are saying. You are saying that the programmer must 
carefully study the cache architecture, and adapt the source program
accordingly. This means different decisions for different models of
the same architecture, this is really not practical. If you want to
operate that this level, you may as well write in assembler :-)

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

[Robert Dewar]

By the way, I apologize in advance for still using a mailer which does
not generate proper threading headers. I have just completed a transition
from a OS/2 to XP (very painful, and I miss OS/2 in many ways), and from
a nice editor (EPM) to a much less capable one, and this amount of 
transition has been a lot of work. I tried to find a mailer with the
same interface I am used to and proper headers, but the first couple of
attempts failed. So soon I will make a third transition in mailers, 
hopefully not as painful as the other two :-)

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

[Robert Dewar]

> And why not?  If I add the "inline" keyword, I do it for a good reason (I
> want the function inlined).

even if it makes your program run slower? I think most programmers would
answer no .. they write inline to speed up their program, not slow it down
and make it bigger and slower :-)

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

[Bernd Schmidt]

On Sat, 15 Mar 2003, Robert Dewar wrote:

> > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > want the function inlined).
> 
> even if it makes your program run slower? I think most programmers would
> answer no .. they write inline to speed up their program, not slow it down
> and make it bigger and slower :-)

Well, you'd assume the person who adds "inline" has done measurements or
looked at the generated assembly.  Humans are intelligent, something that is
in general not true for computer programs.  A source-level decision with the
"inline" keyword can easily be controlled by the user - unless the compiler
decides that it obviously knows more than the programmer.  In that case,
you either end up completely lacking the necessary control, or growing warts
like "-fobey-inline" or the "always_inline" attribute.


Bernd

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

[Geoff Keating]

> Date: Sat, 15 Mar 2003 20:52:06 +0000 (GMT)
> From: Bernd Schmidt <bernds@redhat.com>

> On Sat, 15 Mar 2003, Robert Dewar wrote:
> 
> > > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > > want the function inlined).
> > 
> > even if it makes your program run slower? I think most programmers would
> > answer no .. they write inline to speed up their program, not slow it down
> > and make it bigger and slower :-)
> 
> Well, you'd assume the person who adds "inline" has done measurements or
> looked at the generated assembly.

Often a mistaken assumption...  and even if this was done, some time
in the past, there's no guarantee that it'll still be valid with the
current sources and current compiler.

>  Humans are intelligent, something that is
> in general not true for computer programs.  A source-level decision with the
> "inline" keyword can easily be controlled by the user - unless the compiler
> decides that it obviously knows more than the programmer.  In that case,
> you either end up completely lacking the necessary control, or growing warts
> like "-fobey-inline" or the "always_inline" attribute.

The compiler can make decisions at a finer granulatity than "never
inline" or "always inline".  It can take the location of the call into
account, for instance.  Thus, it's possible to make the compiler good
enough that it *should* override the inline keyword in some cases.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

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

[Matt Austern]

On Saturday, March 15, 2003, at 12:52  PM, Bernd Schmidt wrote:

> On Sat, 15 Mar 2003, Robert Dewar wrote:
>
>>> And why not?  If I add the "inline" keyword, I do it for a good 
>>> reason (I
>>> want the function inlined).
>>
>> even if it makes your program run slower? I think most programmers 
>> would
>> answer no .. they write inline to speed up their program, not slow it 
>> down
>> and make it bigger and slower :-)
>
> Well, you'd assume the person who adds "inline" has done measurements 
> or
> looked at the generated assembly.

I wouldn't assume that.  I certainly wouldn't assume that most 
programmers have done those measurements on every architecture they're 
compiling for.

I haven't taken a survey, but my guess is that most programmers who use 
'inline' use it to mean something like this: "Here's a small function 
that I think should often be inlined, so I'm putting it in the header 
file to make it available for inlining in every translation unit where 
it's used."  It's a mistake to think that the language guarantees 
anything more than that, and I don't think most programmers make that 
mistake.

			--Matt

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

[Joe Buck]

On Sat, Mar 15, 2003 at 02:20:42PM -0500, Robert Dewar wrote:
> > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > want the function inlined).
> 
> even if it makes your program run slower? I think most programmers would
> answer no .. they write inline to speed up their program, not slow it down
> and make it bigger and slower :-)

My take on the matter: if the programmer said "inline", gcc should honor
this directive except in situations where doing so is not possible (e.g.
the function is invoked as a virtual call or via a pointer, or it's
recursive), or there is some reason that correctly inlining the function
would be extremely difficult to implement (example: the order in which
the functions and declarations appear require too much lookahead, or
non-inline declarations are followed by uses and then only later by
inline definitions, as can occur in C++).  If the resulting code is bigger
and slower, make it bigger and slower, but let's get real: gcc's current
heuristics are too stupid to have any idea whether inling a call will
make the program bigger and slower or not.  Given that, we shouldn't be
punishing programmers who measure carefully in an effort to baby-sit those
who use "inline" without thinking.

I am well aware that the standard states that "inline" is advisory, 
but in a high-quality implementation this should be taken to just cover
the cases where inlining the call is not possible or is extremely difficult.
If the compiler can honor the user's request without jumping through
too many hoops, it should do so.

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

[Robert Dewar]

> 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 [*]

That's an odd thing to say, given that both the Ada and the C standards find
that it serves a useful purpose even if the compiler can override. Of course
the randomly here is just rhetoric. You might as well say "if multiplication
can randomly be implemented by repeated addition, then it no longer serves
a useful purpose" [note that of course the language standard certainly permits
this implementation of multiplication].

What the inline keyword means is

"Speed is really important when calling this small function, you can if you
like use more space if it helps execution speed.

 I am guessing that a good idea would be to
inline the code at the point of each call and that this would help execution
speed. I base this guess on a naive view that the function likely generates
only a few instructions, so that the overhead of the instructions for
calling and returning will be significant, and this kind of inlining can
get rid of this overhead"

Now the compiler should react to this by actually doing the inlining if
indeed doing so can reasonbly be expected to improve execution time. But
there are a number of reasons why this may not be the case, often very
target dependent. Some examples:

  1. Increasing code space can increase instruction cache pressure, which
     is often a key element in execution efficiency.

  2. In some architectures, the call can help improve efficiency. For
     example, on the IBM 360, code has to be based, calling a function
     automatically bases the code, avoiding the need for allocating an
     extra base register and mucking with it.

  3. On some machines calls are particularly fast. For example, on the
     INMOS transputer, a call is remarkably fast, often close to free.

  4. A call is an unconditional jump, so is a simple return. On an
     architecture with good branch prediction and plenty of ILP it
     may well be the case that the call is operationally close to free

On the other side of the equation you have to worry about cache effects
requiring constant icache swapping. This occurs most often on a machine
with a one way direct icache. In fact this is such a potentially serious
effect that I would say that on such a machine, inline should almost
always be obeyed, but there are very few such machines around any more
(are there any?). Certainly a C programmer cannot be expected to mess
with inline directives based on the cache architecture, that sort of
thing is unreasonable and undesirable.

How does inline compare with register? The meaning of register is that
in the programmer's estimation, it is worth keeping a given variable in
a register. More accurately, the programmer is saying that references to
the variable will be frequent. Why do the above arguments for inline
not apply to register. Several reasons:

  Although we can enumerate the four points above, the fact of the matter
  is that the decision to inline is far more target independent than the
  selection of registers, which is so dependent on number of registers and
  ABI rules for register usage.

  Register allocation is for the most part a matter of local decision within
  a unit, whereas inlining is important across units. Compilers are rather
  good at decision making within a unit, much worse at interunit decisions.
  Indeed the best argument for register declarations is when they apply
  globally across units.

  We have really good algorithms in practice for figuring out what to put
  in registers. Partly this is because the problem is more studied than
  the inlining case, partly it is because it is more tractable.

  The register declaration is all or nothing, but a good compiler will
  decide to keep something in a register for some particular region
  of code and in memory for another part of the code.

So in practice, most compilers ignore register keywords, and I have not
seen programmers being outraged that their register variables are not
always in registers (they sure would get outraged a lot on the x86 if
they thought this, unless their code was desigfned for a PDP-11 :-)

It is indicative, as someone has pointed out, that the register keyword
was there early on in C compilers, allowing very small naive C compilers
to generate reasonable code without optimization or elaborate register
allocation algorithms.

On the other hand, the inline keyword is much more recent. Pragma Inline
has always been in Ada, and there was absolutely not even a slight
suggestion that it should be removed or deprecated in Ada 95, since in
practice it has proved very useful. It does not guarantee inlining, but
with reasonable Ada compilers that have appeared (including GNAT) it
does indeed provide a very useful tool for Ada programmers. There is the
additional issue in Ada of generating extra dependencies.

An interesting note is that in classical Ada compilers, you can only inline
from units that have already been compiled (analogous to the quite annoying
restriction of only inlining bodies that you have already seen). This means
that two mutually recursive packages cannot inline in both directions
(worse, the code you get depends on the order of compilation). In GNAT,
using the source based approach (for which we have rms to thank, see below)
we can fully respect inlining even in this mutually recursive case and the
code never depends on the order of compilation.

Robert

(post note). The source based approach in Ada comes from a discussion around
1991 with RMS. He was outraged at the idea that the meaning of a program
depended on the order of compilation. We patiently explained (thinking from
the point of view of a traditional library based Ada compiler, which the
Ada standard seems to expect) that this was required in Ada. Well RMS was
not the kind of person to be convinced that a point is wrong when the only
counter argument is to wave a standard around :-) He felt that not only
was it pragmatically undesirable that the meaning of a program depends on
the order of compilation, but also that it was fundamentally philosphically
unacceptable, since the result is that the sources of a program do not
embody its meaning without the additional non-source information of what
order to compile in. After a long to-and-fro discussion (which should
have been preserved but unfortunately was not) we devised the sources based
compilation approach and realized that it was as-if conformant to the Ada 83
standard (the Ada 95 standard has been rewritten to make this approach more
clearly conformant, and other Ada compilers have "borrowed" this source
based approach from GNAT :-)

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

[Andreas Schwab]

dewar@gnat.com (Robert Dewar) writes:

|> Now the compiler should react to this by actually doing the inlining if
|> indeed doing so can reasonbly be expected to improve execution time. But
|> there are a number of reasons why this may not be the case, often very
|> target dependent. Some examples:
|> 
|>   1. Increasing code space can increase instruction cache pressure, which
|>      is often a key element in execution efficiency.
|> 
|>   2. In some architectures, the call can help improve efficiency. For
|>      example, on the IBM 360, code has to be based, calling a function
|>      automatically bases the code, avoiding the need for allocating an
|>      extra base register and mucking with it.
|> 
|>   3. On some machines calls are particularly fast. For example, on the
|>      INMOS transputer, a call is remarkably fast, often close to free.
|> 
|>   4. A call is an unconditional jump, so is a simple return. On an
|>      architecture with good branch prediction and plenty of ILP it
|>      may well be the case that the call is operationally close to free

On the other hand, inlining a function can create great opportunities for
constant folding.  This is the point where gcc is currently very weak
because it bases its heuristics on the unfolded size of the inline
function.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Bernd Schmidt]

On Sat, 15 Mar 2003, Robert Dewar wrote:

> What the inline keyword means is
> 
> "Speed is really important when calling this small function, you can if you
> like use more space if it helps execution speed.
> 
>  I am guessing that a good idea would be to
> inline the code at the point of each call and that this would help execution
> speed. I base this guess on a naive view that the function likely generates
> only a few instructions, so that the overhead of the instructions for
> calling and returning will be significant, and this kind of inlining can
> get rid of this overhead"

Paraphrased, this is equivalent to "I really don't know what's going on here,
please make a decision for me".  We have support for this, it's called
"-finline-functions".  For trivial situations like the one you describe, the
compiler can usually make a good guess.

However, "inline" can mean different things as well.  For example,
  "I know that this function is always called with constant arguments and
  that'll allow you to constant fold all the if statements in the innermost
  loop if you inline it as I told you to.  Please ignore the fact that it's
  large, all the call sites are otherwise empty functions that aren't
  themselves inlined, and only one of them is ever going to be used at
  runtime, so please ignore icache pressure as well since there isn't any."

Or, as much as you may dislike it,
  "This code will only ever run on a VAX.  With typical input, I've measured
  that it runs twice as fast if the function is inlined.  If it ever runs on
  anything other than a VAX we'll redo the measurements."

> Now the compiler should react to this by actually doing the inlining if
> indeed doing so can reasonbly be expected to improve execution time.

IMO this problem is AI-complete.


Bernd

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

[Robert Dewar]

> always_inline is just extra clutter, either in the sources or in the Makefile.

I disagree. I think that always_inline should be used *only* if there is a 
functional requirement (not just an efficiency requirement) for inlining. And
such situations are unusual, and to me require a specific comment anyway, so
if you have a specific comment, it may as well be attached to the
attribute specification.

> This breaks existing programs; not in the sense of
> causing them to fail to compile or work, but by causing severe performance
> regressions.

But if there are "severe performance regressions" caused by the compiler not
recognizing inline when it should, that's a serious problem that should be
addressed, not by a kludge requiring programmer messing, but by fixing the
compiler. For addressing that, it would seem to me that examples woul dbe
most useful.

One interesting point here is that in the case of Ada, we find that the
compiler makes quite reasonable decisions for pragma Inline, it does not
*always* inline every instance of pragma Inline, which is why we have
Always_Inline, and in particular, we require a switch to activate inlining,
and Always_Inline inlines even in the absence of this switch. But the
heuristics used for inlining seem to work pretty well. Indeed the only
trouble we have had with inlining is people using -O3 and degrading
performance, since -O3 typically does too much inlining, especially in
a program where the programmer has already decided what should be inlined.

> It's the change in behaviour from previous versions that bothers me

That's certainly a legitimate concern. I think the most useful thing would
be real examples where there is a significant change in performance, since
the objective should be to improve the handling of inline by default.

> this is the reason why I would like something like -fobey-inline as default.

That seems undesirable to me, there may be legitimate reasons for refusing
to inline a function (e.g. performance reasons, if you have a huge function
with many calls, then the code explosion is very likely to degrade
performance by degrading icache performance).
y
 

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

[Daniel Jacobowitz]

On Sat, Mar 15, 2003 at 01:27:45PM -0500, Robert Dewar wrote:
> > It's the change in behaviour from previous versions that bothers me
> 
> That's certainly a legitimate concern. I think the most useful thing would
> be real examples where there is a significant change in performance, since
> the objective should be to improve the handling of inline by default.

Several have already been posted in this thread, including one
C++-heavy test which requires inlining limits probably considerably
higher than are "generally" appropriate.

After the most recent inlining patches, we have a mechanism to set
different thresholds for automatic and explicit inlining, I believe. 
Whatever is decided about -fobey-inline, I suspect that the explicit
(max_inline_insns_single?) threshold needs to be bumped _way_ up.

> > this is the reason why I would like something like -fobey-inline as default.
> 
> That seems undesirable to me, there may be legitimate reasons for refusing
> to inline a function (e.g. performance reasons, if you have a huge function
> with many calls, then the code explosion is very likely to degrade
> performance by degrading icache performance).

Sure.  The programmer had better know that if he's marking things
inline.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Richard Earnshaw]

> > this is the reason why I would like something like -fobey-inline as default.
> 
> That seems undesirable to me, there may be legitimate reasons for refusing
> to inline a function (e.g. performance reasons, if you have a huge function
> with many calls, then the code explosion is very likely to degrade
> performance by degrading icache performance).

Or causing excessive spilling.

R.

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

[Robert Dewar]

> No, if the function is marked inline incorrectly the programmer should 
> discover it and remove the it himself. C is not a language there the 
> semantics mean: "I have no idea what I am doing, so please to whatever you 
> want with what I write".

I strongly disagree with this. In normal usage, inline simply means "I really
want calls to this to be as fast as possible, and if necessary sacrifice space
for speed". If a compiler knows that it is not significantly helpful, or possibly
that it is even unhelpful to inline, then it is silly to inline. Furthermore, this
does not correspond to a mistake in the C program, since it may be target dependent
whether inlining is significantly helpful (on machines with very small icaches,
inlining big functions very often results in slower performance).

I do think it is useful to have a switch which causes warnings to be generated
in cases where the compiler could not, or would not do the inlining, most helpfully
with an indication of why not.

Yes, as we all agree, there are cases where inline is NOT about speed but
but about functionality, and in such cases, the inlines should be specially
marked.

As for the quote about C, I think it's a bit off target. These days with modern
processors, C like any other high level language is very much a language where
the semantics mean "I have no idea what machine language should be generated
for this, I expect you to figure out the fastest/smallest appropriate machine
language." Yes, this is a change from the old PDP-11 days :-)

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

[Robert Dewar]

> Sometimes.  But this isn't really an argument we need to have, since 
> the two of us agree that (a) gcc as it stands now shouldn't ignore the 
> 'inline' keyword, and (b) there should be some kind of mechanism for 
> programmers to force inlining in the unusual circumstances where they 
> need that kind of low-level control.

I agree!

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

[Robert Dewar]

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

It's dubious even for a "state of the art optimizing compiler" The programmer
often knows better than any compiler what should be inlined.

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

[Matt Austern]

On Friday, March 14, 2003, at 10:08  AM, Robert Dewar wrote:

>> 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.)
>
> It's dubious even for a "state of the art optimizing compiler" The 
> programmer
> often knows better than any compiler what should be inlined.

Sometimes.  But this isn't really an argument we need to have, since 
the two of us agree that (a) gcc as it stands now shouldn't ignore the 
'inline' keyword, and (b) there should be some kind of mechanism for 
programmers to force inlining in the unusual circumstances where they 
need that kind of low-level control.

			--Matt

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

[Andreas Schwab]

dewar@gnat.com (Robert Dewar) writes:

|> It's dubious even for a "state of the art optimizing compiler" The programmer
|> often knows better than any compiler what should be inlined.

The same has been said about register ....

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Joe Buck]

dewar@gnat.com (Robert Dewar) writes:
> |> It's dubious even for a "state of the art optimizing compiler" The programmer
> |> often knows better than any compiler what should be inlined.

On Fri, Mar 14, 2003 at 09:00:39PM +0100, Andreas Schwab wrote:
> The same has been said about register ....

There are important differences.

In the case of the kernel programmers, they most emphatically *do* know
that a function marked inline must be inline, because there are points in
the kernel where there is not even a stack.  In such cases, the decision
about whether to do inlining simply cannot be left to the compiler.

As for other cases, gcc's current inlining heuristics aren't very good, so
your analogy to the "register" keyword does hold up.  Ten or 15 years ago,
the state of the art of compilers was such that programmer use of the
"register" keyword yielded substantially better code; now this is no
longer true.  Maybe a few years from now, gcc will make better decisions
about inlining.  But at the moment, the programmers I work with carefully
study gprof or Quantify reports, determine which functions need to be
inlined, add the "inline" keyword, and scream when gcc thinks it knows
better (hint: it doesn't).

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

[Geoff Keating]

Joe Buck <jbuck@synopsys.com> writes:

> dewar@gnat.com (Robert Dewar) writes:
> > |> It's dubious even for a "state of the art optimizing compiler" The programmer
> > |> often knows better than any compiler what should be inlined.
> 
> On Fri, Mar 14, 2003 at 09:00:39PM +0100, Andreas Schwab wrote:
> > The same has been said about register ....
> 
> There are important differences.
> 
> In the case of the kernel programmers, they most emphatically *do* know
> that a function marked inline must be inline, because there are points in
> the kernel where there is not even a stack.  In such cases, the decision
> about whether to do inlining simply cannot be left to the compiler.

This is true for some functions marked inline in the kernel, but not
for all of them; some are marked inline just for speed.  That's why a
global flag like -fobey-inline is a bad idea, and the attribute that
we have now is a good idea.

> As for other cases, gcc's current inlining heuristics aren't very good, so
> your analogy to the "register" keyword does hold up.  Ten or 15 years ago,
> the state of the art of compilers was such that programmer use of the
> "register" keyword yielded substantially better code; now this is no
> longer true.  Maybe a few years from now, gcc will make better decisions
> about inlining.  But at the moment, the programmers I work with carefully
> study gprof or Quantify reports, determine which functions need to be
> inlined, add the "inline" keyword, and scream when gcc thinks it knows
> better (hint: it doesn't).

That's an argument that GCC should give more weight to the inline
keyword now, but not an argument that GCC should promise to obey it
slavishly in the future.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

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

[Allan Sandfeld]

On Saturday 15 March 2003 00:50, Geoff Keating wrote:
> Joe Buck <jbuck@synopsys.com> writes:
> > dewar@gnat.com (Robert Dewar) writes:
> > > |> It's dubious even for a "state of the art optimizing compiler" The
> > > |> programmer often knows better than any compiler what should be
> > > |> inlined.
> >
> > On Fri, Mar 14, 2003 at 09:00:39PM +0100, Andreas Schwab wrote:
> > > The same has been said about register ....
> >
> > There are important differences.
> >
> > In the case of the kernel programmers, they most emphatically *do* know
> > that a function marked inline must be inline, because there are points in
> > the kernel where there is not even a stack.  In such cases, the decision
> > about whether to do inlining simply cannot be left to the compiler.
>
> This is true for some functions marked inline in the kernel, but not
> for all of them; some are marked inline just for speed.  That's why a
> global flag like -fobey-inline is a bad idea, and the attribute that
> we have now is a good idea.
>
No, if the function is marked inline incorrectly the programmer should 
discover it and remove the it himself. C is not a language there the 
semantics mean: "I have no idea what I am doing, so please to whatever you 
want with what I write".

`Allan

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

[Bernd Schmidt]

On 14 Mar 2003, Geoff Keating wrote:

> > As for other cases, gcc's current inlining heuristics aren't very good, so
> > your analogy to the "register" keyword does hold up.  Ten or 15 years ago,
> > the state of the art of compilers was such that programmer use of the
> > "register" keyword yielded substantially better code; now this is no
> > longer true.  Maybe a few years from now, gcc will make better decisions
> > about inlining.  But at the moment, the programmers I work with carefully
> > study gprof or Quantify reports, determine which functions need to be
> > inlined, add the "inline" keyword, and scream when gcc thinks it knows
> > better (hint: it doesn't).
> 
> That's an argument that GCC should give more weight to the inline
> keyword now, but not an argument that GCC should promise to obey it
> slavishly in the future.

And why not?  If I add the "inline" keyword, I do it for a good reason (I
want the function inlined).  I don't see why the compiler has to make me
beg for it with "always_inline" when I've already made my intention clear.
If someone wants the compiler to guess for them, they should use
"-finline-functions" and hope someone fixes the heuristics.  The current
behaviour of "inline" is simply not predictable by the user, and hence it
is useless.


Bernd

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

[Alexandre Oliva]

On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:

> And why not?  If I add the "inline" keyword, I do it for a good reason (I
> want the function inlined).

What if you don't add the `inline' keyword, but define a member
function inside the class body in C++?  Per the C++ Standard, such a
member function is implicitly `inline'.  Must this inline marker get
the same weight as a function defined outside the class body, with the
inline keyword explicitly given?

> I don't see why the compiler has to make me beg for it with
> "always_inline" when I've already made my intention clear.

always_inline is an entirely different matter.  always_inline is about
`inline or die', not about `inline or it will be slower'.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

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

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
| 
| > And why not?  If I add the "inline" keyword, I do it for a good reason (I
| > want the function inlined).
| 
| What if you don't add the `inline' keyword, but define a member
| function inside the class body in C++?  Per the C++ Standard, such a
| member function is implicitly `inline'.  Must this inline marker get
| the same weight as a function defined outside the class body, with the
| inline keyword explicitly given?

From my perspective, the answer is clear cut : yes.

The in-class definition isn't done lightly, just like putting the
inline specifier if the function were defined outside the class.

I can't see why that would even be a question of debate.
(Yes, I know that GCC used, in the past, to be doing a silly
distinction but  that was silly).

-- Gaby

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

[Joe Buck]

On Sun, Mar 16, 2003 at 03:41:17PM -0300, Alexandre Oliva wrote:
> On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
> 
> > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > want the function inlined).
> 
> What if you don't add the `inline' keyword, but define a member
> function inside the class body in C++?  Per the C++ Standard, such a
> member function is implicitly `inline'.  Must this inline marker get
> the same weight as a function defined outside the class body, with the
> inline keyword explicitly given?

I would be willing to accept as a compromise that such implicit inline
requests are somehow "weaker" than explicit use of the inline keyword.
But it's frustrating to have to write nonstandard C++ (sorry, use of
GNU directives is nonstandard) to get the compiler to behave as requested
when the word "inline" is explicitly typed.

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

[Ross Smith]

On Tuesday, 18 March 2003 05:31, Joe Buck wrote:
> On Sun, Mar 16, 2003 at 03:41:17PM -0300, Alexandre Oliva wrote:
> > On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
> > > And why not?  If I add the "inline" keyword, I do it for a good
> > > reason (I want the function inlined).
> >
> > What if you don't add the `inline' keyword, but define a member
> > function inside the class body in C++?  Per the C++ Standard, such
> > a member function is implicitly `inline'.  Must this inline marker
> > get the same weight as a function defined outside the class body,
> > with the inline keyword explicitly given?
>
> I would be willing to accept as a compromise that such implicit
> inline requests are somehow "weaker" than explicit use of the inline
> keyword. But it's frustrating to have to write nonstandard C++
> (sorry, use of GNU directives is nonstandard) to get the compiler to
> behave as requested when the word "inline" is explicitly typed.

The vast majority of inline functions in modern C++ are templates. 
Templates _have_ to be inline, either defined inside a class definition 
or explicitly marked inline if they're defined out of line or aren't 
class members. There's no portable way to use templates without marking 
them inline.

That means most inline functions in C++ are that way because they have 
to be to make the syntax work, with no reason to suspect that they're 
more deserving of actual inlining than any other functions. Giving high 
weight to the inline tag is undoubtedly one of the reasons why GCC 
produces inferior code to smarter compilers like Intel's.

I'd like to see GCC simply ignore the inline tag in its inlining 
heuristics. This would certainly produce better code from C++ than the 
current system; the rare cases when the compiler isn't smart enough to 
inline something that should be inlined will be vastly outweighed by 
the enormous number of functions that shouldn't be inlined but have to 
be tagged inline because of a language misfeature.

Failing that, at least don't make the situation any worse than it 
already is. You C programmers can do what you like, but for C++, don't 
even think about giving inline any more weight than it has now; it 
already has far too much.

-- 
Ross Smith ......... r-smith@ihug.co.nz ......... Auckland, New Zealand

Eagles may soar, but weasels never get sucked into a land war in Asia.

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

[Joe Buck]

On Tue, Mar 18, 2003 at 07:18:30AM +1200, Ross Smith wrote:
> The vast majority of inline functions in modern C++ are templates. 
> Templates _have_ to be inline, either defined inside a class definition 
> or explicitly marked inline if they're defined out of line or aren't 
> class members. There's no portable way to use templates without marking 
> them inline.

This is not correct.  The template has to appear in the header; it need
not be declared inline.
 

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

[Ross Smith]

On Tuesday, 18 March 2003 07:22, you wrote:
> On Tue, Mar 18, 2003 at 07:18:30AM +1200, Ross Smith wrote:
> > The vast majority of inline functions in modern C++ are templates.
> > Templates _have_ to be inline, either defined inside a class
> > definition or explicitly marked inline if they're defined out of
> > line or aren't class members. There's no portable way to use
> > templates without marking them inline.
>
> This is not correct.  The template has to appear in the header; it
> need not be declared inline.

Yes it does. A function defined in a header but not inline will trigger 
ODR violations as soon as more than one module includes it.

-- 
Ross Smith ......... r-smith@ihug.co.nz ......... Auckland, New Zealand

Eagles may soar, but weasels never get sucked into a land war in Asia.

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

[Gabriel Dos Reis]

Ross Smith <r-smith@ihug.co.nz> writes:

| On Tuesday, 18 March 2003 07:22, you wrote:
| > On Tue, Mar 18, 2003 at 07:18:30AM +1200, Ross Smith wrote:
| > > The vast majority of inline functions in modern C++ are templates.
| > > Templates _have_ to be inline, either defined inside a class
| > > definition or explicitly marked inline if they're defined out of
| > > line or aren't class members. There's no portable way to use
| > > templates without marking them inline.
| >
| > This is not correct.  The template has to appear in the header; it
| > need not be declared inline.
| 
| Yes it does.

No, it does not.  Check out the C++ definition.

| A function defined in a header but not inline will trigger 
| ODR violations as soon as more than one module includes it.

Templates have special status.  See the chapter on implicit instantiations.
Have a look at the "Template instantiation" in the GCC manual.

-- Gaby

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

[Ross Smith]

On Tuesday, 18 March 2003 18:27, you wrote:
> Ross Smith <r-smith@ihug.co.nz> writes:
> | On Tuesday, 18 March 2003 07:22, you wrote:
> | > On Tue, Mar 18, 2003 at 07:18:30AM +1200, Ross Smith wrote:
> | > > The vast majority of inline functions in modern C++ are
> | > > templates. Templates _have_ to be inline, either defined inside
> | > > a class definition or explicitly marked inline if they're
> | > > defined out of line or aren't class members. There's no
> | > > portable way to use templates without marking them inline.
> | >
> | > This is not correct.  The template has to appear in the header;
> | > it need not be declared inline.
> |
> | Yes it does.
>
> No, it does not.  Check out the C++ definition.

Could you be more specific please? Reading 14.5.5 (function templates) 
and 14.7.1 (implicit instantiation) turns up nothing relevant, as far 
as I can see. 3.2 (one definition rule) para 3 says "Every program 
shall contain exactly one definition of every non-inline function or 
object that is used in that program", which seems pretty clear to me.

> | A function defined in a header but not inline will trigger
> | ODR violations as soon as more than one module includes it.
>
> Templates have special status.  See the chapter on implicit
> instantiations. Have a look at the "Template instantiation" in the
> GCC manual.

I'm aware of the way this works in GCC. This is explicitly documented as 
a GCC _extension_ to C++ (albeit one also implemented by several other 
compilers). I didn't say there was no way to do it, I said there was no 
_portable_ way to do it.

-- 
Ross Smith ......... r-smith@ihug.co.nz ......... Auckland, New Zealand

Eagles may soar, but weasels never get sucked into a land war in Asia.

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

[Matt Austern]

On Tuesday, March 18, 2003, at 09:31  AM, Ross Smith wrote:
> Could you be more specific please? Reading 14.5.5 (function templates)
> and 14.7.1 (implicit instantiation) turns up nothing relevant, as far
> as I can see. 3.2 (one definition rule) para 3 says "Every program
> shall contain exactly one definition of every non-inline function or
> object that is used in that program", which seems pretty clear to me.

Function templates aren't functions.

			--Matt

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

[Fergus Henderson]

On 19-Mar-2003, Ross Smith <r-smith@ihug.co.nz> wrote:
> Could you be more specific please? Reading 14.5.5 (function templates) 
> and 14.7.1 (implicit instantiation) turns up nothing relevant, as far 
> as I can see. 3.2 (one definition rule) para 3 says "Every program 
> shall contain exactly one definition of every non-inline function or 
> object that is used in that program", which seems pretty clear to me.

As Matt noted, function templates aren't functions.
The relevant text is 3.2 [basic.def.odr] paragraph 5:

   There can be more than one definition of a class type (clause
   class), enumeration type (dcl.enum), inline function with external
   linkage (dcl.fct.spec), CLASS TEMPLATE (clause temp), non-static   
   FUNCTION TEMPLATE (temp.fct), static data member of a class template
   (temp.static), MEMBER FUNCTION TEMPLATE (temp.mem.func), or template
   specialization for which some template parameters are not specified
   (temp.spec, temp.class.spec) in a program provided that each
   definition appears in a different translation unit, and provided the
   definitions satisfy the following requirements.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

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

[Gabriel Dos Reis]

Ross Smith <r-smith@ihug.co.nz> writes:

| On Tuesday, 18 March 2003 05:31, Joe Buck wrote:
| > On Sun, Mar 16, 2003 at 03:41:17PM -0300, Alexandre Oliva wrote:
| > > On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
| > > > And why not?  If I add the "inline" keyword, I do it for a good
| > > > reason (I want the function inlined).
| > >
| > > What if you don't add the `inline' keyword, but define a member
| > > function inside the class body in C++?  Per the C++ Standard, such
| > > a member function is implicitly `inline'.  Must this inline marker
| > > get the same weight as a function defined outside the class body,
| > > with the inline keyword explicitly given?
| >
| > I would be willing to accept as a compromise that such implicit
| > inline requests are somehow "weaker" than explicit use of the inline
| > keyword. But it's frustrating to have to write nonstandard C++
| > (sorry, use of GNU directives is nonstandard) to get the compiler to
| > behave as requested when the word "inline" is explicitly typed.
| 
| The vast majority of inline functions in modern C++ are templates. 
| Templates _have_ to be inline, either defined inside a class definition 
| or explicitly marked inline if they're defined out of line or aren't 
| class members. There's no portable way to use templates without marking 
| them inline.

I strongly disagree with the above statements.

Non-exported template definitions need -not- be marked inline.  And in
effect,  the GNU standard library implementation gas lots of template
code with no explicit inline specifier.

-- Gaby

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

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.com> writes:

| On Sun, Mar 16, 2003 at 03:41:17PM -0300, Alexandre Oliva wrote:
| > On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
| > 
| > > And why not?  If I add the "inline" keyword, I do it for a good reason (I
| > > want the function inlined).
| > 
| > What if you don't add the `inline' keyword, but define a member
| > function inside the class body in C++?  Per the C++ Standard, such a
| > member function is implicitly `inline'.  Must this inline marker get
| > the same weight as a function defined outside the class body, with the
| > inline keyword explicitly given?
| 
| I would be willing to accept as a compromise that such implicit inline
| requests are somehow "weaker" than explicit use of the inline keyword.

That would be a disaster on STL-like code where function-object's
operator() are commonly defined in the enclosing class.  I can't see
any compeling reason why we should introduce that artificial distinction.

-- Gaby

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

[Joe Buck]

On Mon, Mar 17, 2003 at 09:11:38PM +0100, Gabriel Dos Reis wrote:
> | I would be willing to accept as a compromise that such implicit inline
> | requests are somehow "weaker" than explicit use of the inline keyword.
> 
> That would be a disaster on STL-like code where function-object's
> operator() are commonly defined in the enclosing class.  I can't see
> any compeling reason why we should introduce that artificial distinction.

I'm not talking about making that any worse: by "weaker", I meant,
essentially, to handle inlining the way it is currently handled for such
cases, where inline is considered less mandatory than it was in the past,
while the keyword would mean "inline it if at all possible".

However, my preference would be just to inline all that the language
suggests will be inlined.  If this causes code size bloat and icache
saturation, the user has the available means to correct this (move
function definitions out-of-line).

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

[Richard Earnshaw]

> On Sun, Mar 16, 2003 at 03:41:17PM -0300, Alexandre Oliva wrote:
> > On Mar 15, 2003, Bernd Schmidt <bernds@redhat.com> wrote:
> > 
> > > And why not?  If I add the "inline" keyword, I do it for a good reason (I
> > > want the function inlined).
> > 
> > What if you don't add the `inline' keyword, but define a member
> > function inside the class body in C++?  Per the C++ Standard, such a
> > member function is implicitly `inline'.  Must this inline marker get
> > the same weight as a function defined outside the class body, with the
> > inline keyword explicitly given?
> 
> I would be willing to accept as a compromise that such implicit inline
> requests are somehow "weaker" than explicit use of the inline keyword.
> But it's frustrating to have to write nonstandard C++ (sorry, use of
> GNU directives is nonstandard) to get the compiler to behave as requested
> when the word "inline" is explicitly typed.
> 

Sitting back and thinking about this whole discussion I realise that there 
is a major distinction between -finline-functions and the inline keyword.  
The distinction lies in what may be assumed to be safe when inlining.

The C99 draft rationale cites an example of code that can behave 
differently when inlined from when it is not (though mainly in the case 
where the code is compiled into separate compilation units).  If we are 
considering inlining a call purely because of -finline-functions, then GCC 
had better be certain that doing so will not change the meaning of the 
program.  However, the presence of the inline keyword does indicate to the 
compiler that certain potentially ambiguous meanings can be ignored -- the 
programmer is effectively asserting that the ambiguities don't matter.

It seems that we are all getting very hung up over the issues that 
optimization is only about speed of the executable, that inlining should 
only be done after real measurements have been taken and that an 
application will only ever be written to run on one architecture.  While 
all of these considerations are true for some applications they can all 
clearly be false for others; and in probably the majority of cases at 
least one will not be true.  GCC is a compiler that targets many people 
who use it in many ways and we must take account of all users in any 
decision we reach or we will end up alienating everybody eventually.

Fact: some users want their application to be optimized for space.  In 
these circumstances we should probably only inline if code size will be 
reduced -- an example would be a single use of a static function, or when 
inlining will produce less code than the overhead of setting up a call 
(initializing arguments etc).

Fact: some users want their code to run on many platforms.  What then 
constitutes a good function to inline will depend on the platform (does it 
have only four registers, sixteen, or sixty-four?).  They don't want to do 
full measurements on every one, and even if they did they'd probably end 
up with conflicting answers.  They want the compiler to use its judgement 
as to when it is worthwhile to inline and when it is not.

I think what I'm trying to say is that we all accept that GCC's current 
inlining heuristics are broken and that it far too often fails to inline 
code that would be a good candidate for inlining.  But going to the other 
extreme would be equally wrong for another class of user.  We need to find 
the acceptable middle ground, which can only be done by making the 
compiler smarter, not by using a sledge-hammer.

Finally, I would also note that a compiler should also be free to 
un-inline parts of a function (factor them out into subroutine calls) if 
doing so allows it to satisfy the requested compilation goals.  The source 
code is simply a semantic expression of the problem.  There is no absolute 
requirement that the compiled code match its structure in terms of the 
blocks of assembly code that it generates, only that it match its meaning.

R.

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

[Joseph S. Myers]

On Tue, 18 Mar 2003, Richard Earnshaw wrote:

> Finally, I would also note that a compiler should also be free to 
> un-inline parts of a function (factor them out into subroutine calls) if 
> doing so allows it to satisfy the requested compilation goals.  The source 
> code is simply a semantic expression of the problem.  There is no absolute 
> requirement that the compiled code match its structure in terms of the 
> blocks of assembly code that it generates, only that it match its meaning.

Past discussion of the inline heuristics problem on this list has
mentioned region-based compilation which involves the compiler generally
dividing the program into better units than the source functions.  With
such a framework, "inline" would be just one hint to be used together with
other analysis of the program and possible profile feedback.  
<http://gcc.gnu.org/ml/gcc/2001-07/msg00692.html> has a link to a paper.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

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

[Robert Dewar]

> >For example, in the Ada standard, if you write
> >
> >   a := x / y;
> >
> >where y is 1.0, and Machine_Overflows is false for the floating-point type in
> >question, then the result is "unspecified". This means that the compiler could
> >generate code to send denial-of-service-attacks to the internet root servers,
> >and you would not be violating the standard, but you would not get many
> >customers for your compiler. What users would expect here on an IEEE machine
> >is to get infinities, even though the Ada RM says nothing about this possibility.
> >
> >  
> >
> I am not an Ada programmer, but if this is division like I think it
> is, I don't understand why you would expect machine overflow by
> dividing by one. Or is this a typo where you meant "where y is 0.0"?

Some typos are really confusing. Sorry about that, yes, indeed I meant 0.0

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

[Robert Dewar]

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

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

[Richard Earnshaw]

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

FWIW I agree with all of the above.  Particularly with respect to 
addressing the current inadequacies of the current inlining heuristics.

My concerns with respect to the inline_always attribute are to do with 
testing and how we should show that we've inlined things correctly 
(according to the way in which we deem inlining to be done in those corner 
cases).  As with many GCC extensions, we've added a feature without really 
considering the impact it has on the rest of the implementation.

R.

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

[Robert Dewar]

Just to be clear, I absolutely agree that it is useful to have mandator inlining,
and I already gave a completely different reason from the (perfecgtly reasonable)
ones that have been suggested by others (I gave the certification case).

The setjmp/longjmp case is indeed a nice example. I am quite sure that this
example must be undefined in terms of the standard, and the standard is not
just saying "this is undefined, because it is undefined whether inlining occurs".
The reason is more fundamental. The idea of inlining being somehow semantically
equivalent to having the source code actually inlined is conceptually and pragmatically
reasonable, but is way out of scope of the semantic definition in the standard.

So you really can't figure out what this longjmp/setjmp case means from the standard
whether or not inlining actually takes place.

However, in terms of a particular implementation, which enforces inlining, you can
definitely write (undefined, buggy, improper, non-conforming, use whatever adjectives
you feel like) code that does in fact "work" as intended. Yes, of course the code
is not necessarily portable to other compilers etc, but in certain contexts it seems
quite fine to me to use such code if it is well documented, and it is fine to provide
compiler options etc within reason that support such usage.

As an example of this, we do several "nasty non-standard" things in the GNAt library
that we happen to know will work with GNAT, since the run-time library of GNAT is
only ever intended to be compiled with GNAT. Nothing wrong with this (it has 
occasionally inconvenienced users and vendors of other proprietary compilers who
would like to use the GNAT run-time with their compilers, but satisfying that
need is not one of our requirements :-)

Language lawyers who know the standard can tell you that a given program does or does
not have a fully defined behavior according to the standard, but they have no business
telling you that it is always improper to write programs which are not fully defined
in these terms, and compiler writers who think that this viewpoint is legitimate
will meet the letter of the standard, but will fail to provide a maximally usable
compiler.

Note that there is no general principle here. It is neither always right nor always
wrong to use stuff that is outside the standard. Casual use of non-standard features
that derives from ignorance rather than real need should definitely be discouraged
and certainly need not be pandered to. Each case is a judgment call as to whether
the non-standard usage is legitimate enough to be semi-standardized in a particular
compiler.

It seems clear to me that mandatory inlining is something that meets this test, and
should be supported.

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

[Robert Dewar]

> Of course it's not defined behaviour in C99, since it's unspecified 
> whether inlining will take place for any given function -- and hence 
> anything that depends on inlining occuring is then by definition 
> incorrect.  As soon as you make inlining mandatory, these questions start 
> to rear their heads.

Are you sure this is the right exegesis? I would have thought that this was improper
on entirely different grounds (e.g. that if you remove the inline completely it is
still improper).

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

[Richard Earnshaw]

> > Of course it's not defined behaviour in C99, since it's unspecified 
> > whether inlining will take place for any given function -- and hence 
> > anything that depends on inlining occuring is then by definition 
> > incorrect.  As soon as you make inlining mandatory, these questions start 
> > to rear their heads.
> 
> Are you sure this is the right exegesis? I would have thought that this was improper
> on entirely different grounds (e.g. that if you remove the inline completely it is
> still improper).

That's not relevant.  We know the code is incorrect if you never inline.  
The question is whether the code is correct if you always inline.

c99 doesn't have to worry about that situation; since there is no way of 
forcing inline behaviour in the standard then the code must be incorrect.

If we want to allow mandatory inlining then we have to decide whether the 
example is legal or not.  If we decide that it's legal, then we had better 
have a test to ensure we do it correctly.

R.

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

[Segher Boessenkool]

Richard Earnshaw wrote:
> That's not relevant.  We know the code is incorrect if you never inline.  
> The question is whether the code is correct if you always inline.

I don't see any reason the compiler would change language
semantics just because it ensures some certain things
about code generation.

> c99 doesn't have to worry about that situation; since there is no way of 
> forcing inline behaviour in the standard then the code must be incorrect.

It doesn't have to worry about it, because it defines it to
be non-conforming code.

> If we want to allow mandatory inlining then we have to decide whether the 
> example is legal or not.  If we decide that it's legal, then we had better 
> have a test to ensure we do it correctly.

While it might be possible to make longjmp() work with this
example if always inlining, it would not be a good idea to
tell the users they can rely on this working, imho.


Segher

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

[Robert Dewar]

> Ah, but if the inline is performed it's not an expired scope any more.  
> One of
> the early C++ suites did exactly this, expecting the inline to be 
> performed.

No, that's not correct thinking, the expired scope is a semantic concept. The
fact that the undefined effect may be different if inlining takes place or not
means nothing (or at least I would guess this). I can't imagine that somethingt
like this suddently becomes defined if inlining takes place, the C standard
can't be that vague ... but surely someone who knows the standard really well
will read us the chapter and verse :-)

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

[Richard Earnshaw]

> > Ah, but if the inline is performed it's not an expired scope any more.  
> > One of
> > the early C++ suites did exactly this, expecting the inline to be 
> > performed.
> 
> No, that's not correct thinking, the expired scope is a semantic concept. The
> fact that the undefined effect may be different if inlining takes place or not
> means nothing (or at least I would guess this). I can't imagine that somethingt
> like this suddently becomes defined if inlining takes place, the C standard
> can't be that vague ... but surely someone who knows the standard really well
> will read us the chapter and verse :-)

Of course it's not defined behaviour in C99, since it's unspecified 
whether inlining will take place for any given function -- and hence 
anything that depends on inlining occuring is then by definition 
incorrect.  As soon as you make inlining mandatory, these questions start 
to rear their heads.

It's precisely because mandatory inlining can have implications on 
behaviour right across the language that we can't even imagine, let alone 
test that I'm against supporting this type of behaviour.

If we had a precise and complete specification to work to, and tests to 
prove that we were adhering to that specification then there would be less 
of a problem.  At least then we would know when changes in the compiler 
had altered the way a user's program would be compiled.  But even that 
doesn't solve the issue that we repeatedly run across where some existing 
extension prevents us from optimizing a conforming program as well as we 
could do otherwise.

R.

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

[Lars Segerlund]

  Well your code doesn't depend on it does it ?

  Here are some people that have the resonable request of having some 
code mandatory inlined, they have supplied examples of where this is 
necessary ( no stack ( happens in kernel ), and setjmp longjmp ).

  Were all very aware that you think this is a bad idea, however I think 
the debate is taking a religious turn, the setjmp/longjmp example was 
exellent, with an example of where this kind of code had occured and 
might occur ( the lib in question ). Trying to deduce the non compliance 
of this code is silly since that argument is based upon the context, 
i.e. "if it works the way I want it's illegal code" instead of quoting 
that setjmp or longjmp is prohibited to be invoked in this context ( 
which they are not ). The alternative is to make the compiler smart 
enough to inline all functions containing a setjump referensed by a 
longjump, I see no other way to enforce compliance.

  Anyhow it doesn't matter since it's possible to do the same thing 
without the flag, it's a lot of hazzle, it will be done, and it will be 
done in a way which is much more 'ugly'.

  Also for some cases of threaded code this would be vital, ( especially 
threaded libs ), in order to make them easy to code. ( thread safe 
library could be built by adding the flag and a non thread safe by 
omitting ), cases like this will now have to be handled with macros and 
defines which tend to make things a bit ugly when you start hitting a 
couple of KLOC's.

  So whatever feedback people provide doesn't seem to generate an open 
debate but instead the standard response that "they're doing it wrong". 
Which perhaps is not the best argument to convince someone of a standpoint.

  I think, "No we don't need another flag" would be a better argument.

  / sincerely, Lars Segerlund.

Richard Earnshaw wrote:
>>>Ah, but if the inline is performed it's not an expired scope any more.  
>>>One of
>>>the early C++ suites did exactly this, expecting the inline to be 
>>>performed.
>>
>>No, that's not correct thinking, the expired scope is a semantic concept. The
>>fact that the undefined effect may be different if inlining takes place or not
>>means nothing (or at least I would guess this). I can't imagine that somethingt
>>like this suddently becomes defined if inlining takes place, the C standard
>>can't be that vague ... but surely someone who knows the standard really well
>>will read us the chapter and verse :-)
> 
> 
> Of course it's not defined behaviour in C99, since it's unspecified 
> whether inlining will take place for any given function -- and hence 
> anything that depends on inlining occuring is then by definition 
> incorrect.  As soon as you make inlining mandatory, these questions start 
> to rear their heads.
> 
> It's precisely because mandatory inlining can have implications on 
> behaviour right across the language that we can't even imagine, let alone 
> test that I'm against supporting this type of behaviour.
> 
> If we had a precise and complete specification to work to, and tests to 
> prove that we were adhering to that specification then there would be less 
> of a problem.  At least then we would know when changes in the compiler 
> had altered the way a user's program would be compiled.  But even that 
> doesn't solve the issue that we repeatedly run across where some existing 
> extension prevents us from optimizing a conforming program as well as we 
> could do otherwise.
> 
> R.
> 
> 

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

[Robert Dewar]

> #include <setjmp.h>
> static jmp_buf buf;
> inline void x() { setjmp(buf); }
> main() { x(); longjmp(buf); }
> 

I don't know the C standard well enough in my head to be sure, but I would be
*amazed* if this is a semantically valid C program. It can't be right to "wake up"
an expired scope with a longjmp, can it? Of course one can be surprised when it
comes to C :-)

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

[Dale Johannesen]

On Thursday, March 13, 2003, at 07:00  PM, Robert Dewar wrote:

>> #include <setjmp.h>
>> static jmp_buf buf;
>> inline void x() { setjmp(buf); }
>> main() { x(); longjmp(buf); }
>>
>
> I don't know the C standard well enough in my head to be sure, but I 
> would be
> *amazed* if this is a semantically valid C program. It can't be right 
> to "wake up"
> an expired scope with a longjmp, can it? Of course one can be 
> surprised when it
> comes to C :-)

Ah, but if the inline is performed it's not an expired scope any more.  
One of
the early C++ suites did exactly this, expecting the inline to be 
performed.

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

[Ziemowit Laski]

On Thursday, Mar 13, 2003, at 19:00 US/Pacific, Robert Dewar wrote:

>> #include <setjmp.h>
>> static jmp_buf buf;
>> inline void x() { setjmp(buf); }
>> main() { x(); longjmp(buf); }
>>
>
> I don't know the C standard well enough in my head to be sure, but I 
> would be
> *amazed* if this is a semantically valid C program. It can't be right 
> to "wake up"
> an expired scope with a longjmp, can it? Of course one can be 
> surprised when it
> comes to C :-)

Yes, I also suspect that the semantics of the foregoing are undefined 
to begin with. :-)
Besides, won't the compiler simply refuse to inline x() no matter how 
hard you beg it to,
because of the setjmp() call?

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

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

[Robert Dewar]

> There we're making an explicit tradeoff: using aliasing information allows
> much better code generation but indeed will break certain types of
> badly-written code.  But we warn the user of this possibility and support
> a -fno-strict-aliasing if this is a concern of the user.  But the point is
> that the breakage is not gratuitous: there's a good reason for it.

Indeed, and the argument here is more about what the default should be, rather than
whether -fno-strict-aliasing should be supported (I have not seen anyone argue that
supporting this switch threatens the sanity of gcc developers). Actually we have
found that certain unusual constructions in Ada (in particular forcing scalar
parameters to be passed by reference, which is outside normal Ada semantics, but
possible in GNAT using non-standard pragmas) cause unexpected results which can
be "cured" by -fno-strict-aliasing.

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

[Robert Dewar]

>  It's a road that no
> sane developer would want to go down. Why don't you spend the effort to
> get the standard amended if a particular case is important?

Because the standard cannot cover everything. For example, there is no way that
the formal standard can legitimately talk about inlining *requiring* inlining,
because semantically it should be neutral whether inlining takes place, and we
are always talking about an as-if semantic model in a standard. Standards always
get into trouble when they start saying things that are semantic rubbish (my
perspective here is from the point of view of working on language standards
since the early 70's [when I worked on the Algol-68 defining documents].)

Let's take something as simple as defining the semantics of malloc and free. Well
you know that an implementation that completely ignores free is completely
unacceptable, but it is extremely hard to define *whY* that is unacceptable in
a standard. We deliberately leave many things unsaid since they are simply out
of scope. This does not mean they are unimportant, just that they operate at
a different level of abstraction from the standard.

As for sane developers going down this path, I have been in the commercial compiler
field for some 30 years now, and for every compiler I have worked on, there was a
difficult-to-deal with area of things that people expect to work but which are not
mandated by the standard. Yes, they are tough to deal with, but as far as I can tell
they have not driven me insane :-)

> How about C aliasing issues? Those are carefully outlined in the
> standard, and yet we've had perhaps thousands of emails on that subject.

I would say that any C compiler which does not provide a way of bypassing the
aliasing rules (i.e. stopping the optimizer from taking advantage of them, needs
some careful definition), is a poor implementation of C from a pragmatic point
of view. There is far too much legacy "junk" code that in practice cannot be
modified to behave. Obviously GCC itself agrees with this point of view :-)

In the case of Realia COBOL we faced an even more difficult problem which is that
there were bugs in the IBM Mainframe COBOL implementation which 

a) were definitely inconsistent with the standard
b) which were depended on by a lot of legacy code.

We found that it was in practice more essential to provide IBM compatibility than
it was to provide standard compatibility (we did as I remember provide an option
for the behavior there). It was a marginal case, but even marginal things often
show up in the real world of very large legacy programs.

A standard is simply a tool for helping to ensure commonality between what all
compilers implement and what all users expect of these compilers, but it is 
over-simplistic to think that it can do 100% of the job.

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

[Dale Johannesen]

Those of you who think inlining is guaranteed to be semantically neutral
might consider this....

#include <setjmp.h>
static jmp_buf buf;
inline void x() { setjmp(buf); }
main() { x(); longjmp(buf); }

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

[Andrea 'fwyzard' Bocci]

At 18.56 13/03/2003 -0800, Dale Johannesen wrote:
>Those of you who think inlining is guaranteed to be semantically neutral
>might consider this....
>
>#include <setjmp.h>
>static jmp_buf buf;
>inline void x() { setjmp(buf); }
>main() { x(); longjmp(buf); }

Question.

Is the following legal C code ?
It also has different scopes for setjmp() and longjmp(), and it's what I'd 
expect from inlining the above example.

#include <setjmp.h>
static jmp_buf buf;

int main (void) {
   {
     setjmp(buf);
   }
   longjmp(buf);
}

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

[Fergus Henderson]

On 14-Mar-2003, Andrea 'fwyzard' Bocci <fwyzard-gcc@libero.it> wrote:
> Is the following legal C code ?
> It also has different scopes for setjmp() and longjmp(), and it's what I'd 
> expect from inlining the above example.
> 
> #include <setjmp.h>
> static jmp_buf buf;
> 
> int main (void) {
>   {
>     setjmp(buf);
>   }
>   longjmp(buf);
> }

Yes, that is strictly conforming C89 and C99 code.
The criteria is whether the containing function has terminated,
not whether the scope containing the setjmp() has been exited.

However, in C99 there is an exception.  If the scope contains a
variably-modified object, as in the following example, it is
undefined behaviour:

	int main (int argc, char **argv) {
	   {
	     char foo[argc];
	     setjmp(buf);
	   }
	   longjmp(buf);	// undefined behaviour, because foo has
	   			// variably-modified type and is no
				// longer in scope
	}

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

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

[Alexandre Oliva]

On Mar 13, 2003, Dale Johannesen <dalej@apple.com> wrote:

> Those of you who think inlining is guaranteed to be semantically neutral
> might consider this....

This invokes undefined behavior.  Which means there's no law against
making it work against all odds, and inlining is a means to accomplish
that.  OTOH, there's no requirement that it actually does something
useful.  I.e., inlining is sematically-neutral in this regard.

> #include <setjmp.h>
> static jmp_buf buf;
> inline void x() { setjmp(buf); }
> main() { x(); longjmp(buf); }


-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

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

[Segher Boessenkool]

Dale Johannesen wrote:
> Those of you who think inlining is guaranteed to be semantically neutral
> might consider this....
> 
> #include <setjmp.h>
> static jmp_buf buf;
> inline void x() { setjmp(buf); }
> main() { x(); longjmp(buf); }

6.7.4 Function specifiers

3	An inline definition of a function with external
	linkage shall not contain a definition of a
	modifiable object with static storage duration,
	and shall not contain a reference to an
	identifier with internal linkage.

x() has external linkage; buf has internal linkage.
This program is non-conforming.  Either x() should be
declared static, or buf should not.

With that fixed, we still have

7.13.2.1 The longjmp function

2	The longjmp function restores the environment
	saved by the most recent invocation of the setjmp
	macro in the same invocation of the program with
	the corresponding jmp_buf argument. If there has
	been no such invocation, or if the function containing
	the invocation of the setjmp macro has terminated
	execution in the interim, [...] the behavior is
	undefined.

x() has terminated execution when longjmp() is called
(there is a sequence point inbetween), so this program
is non-conforming.

Well that's how I read the standard, but IANALL, of course.

Does this help?


Segher

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

[Richard Kenner]

    How about C aliasing issues? Those are carefully outlined in the
    standard, and yet we've had perhaps thousands of emails on that
    subject.

There we're making an explicit tradeoff: using aliasing information allows
much better code generation but indeed will break certain types of
badly-written code.  But we warn the user of this possibility and support
a -fno-strict-aliasing if this is a concern of the user.  But the point is
that the breakage is not gratuitous: there's a good reason for it.

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

[Robert Dewar]

> This is ridiculous, and absolutely unsupportable. There's no way that we
> can promise the behavior that every user that decides not to program to
> the various language standards will get the behavior that they expect -
> not unless you have a patch to enable the compiler to read the user's
> mind.

If this seems ridiculous and absolutely unsupportable, then I can only say you
must not have spent much time in the real world of supplying real compilers to
real application developers. If you take an adamant "follow-the-standard-or-else"
point of view, you won't get sued, but you will cut down your customer base.

Finding the right balance between completely ignoring requirements outside the
standard, and trying to meet every users request for specific undefined behavior
is not at all easy, but it is part of the job in real world compiler writing.

For example, in the Ada standard, if you write

   a := x / y;

where y is 1.0, and Machine_Overflows is false for the floating-point type in
question, then the result is "unspecified". This means that the compiler could
generate code to send denial-of-service-attacks to the internet root servers,
and you would not be violating the standard, but you would not get many
customers for your compiler. What users would expect here on an IEEE machine
is to get infinities, even though the Ada RM says nothing about this possibility.

I am not at ALL saying that everytime some C programmer writes carelessly 
non-compliant code (e.g. assuming that an int is the same length as a pointer)
should be accomodated with switches or special behavior of the compiler. That
would indeed be "ridiculous and absolutely unsupportable".

But it is also "ridiculous and absolutely unsupportable" to maintain that a compiler
has no responsibilities at all for generating reasonable code in some situations
that are outside the scope of the standard.

This is really similar to performance requirements. It is perfectly standard
compliant to do muptlication using a recursive routine that does it by adding
and subtracting one. But It is not a reasonable approach, even though it is
conforming. Standards tell part of the story of how you must implement a c
compiler, they do not tell the entire story.

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

[Eric Christopher]

> If this seems ridiculous and absolutely unsupportable, then I can only say you
> must not have spent much time in the real world of supplying real compilers to
> real application developers. If you take an adamant "follow-the-standard-or-else"
> point of view, you won't get sued, but you will cut down your customer base.
> 

Only about 6 years, perhaps not long in comparison.

> Finding the right balance between completely ignoring requirements outside the
> standard, and trying to meet every users request for specific undefined behavior
> is not at all easy, but it is part of the job in real world compiler writing.
> 

Of course it is.

> I am not at ALL saying that everytime some C programmer writes carelessly 
> non-compliant code (e.g. assuming that an int is the same length as a pointer)
> should be accomodated with switches or special behavior of the compiler. That
> would indeed be "ridiculous and absolutely unsupportable".
> 

How about C aliasing issues? Those are carefully outlined in the
standard, and yet we've had perhaps thousands of emails on that subject.

> But it is also "ridiculous and absolutely unsupportable" to maintain that a compiler
> has no responsibilities at all for generating reasonable code in some situations
> that are outside the scope of the standard.
> 

"Reasonable" is too vague a word here. Not generating a chess program
into the middle of someone's code is one thing. Ensuring that we can
accurately test (if you support compilers for other people I'm sure
you're familiar with this) for conformance to a particular standard is
far more important than _ensuring_ that someone's broken code behaves
the same way between releases and after every patch. It's a road that no
sane developer would want to go down. Why don't you spend the effort to
get the standard amended if a particular case is important?

-eric

-- 
o/~ got caught stealing fire from the sky o/~

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

[Kevin Handy]

Robert Dewar wrote:

>For example, in the Ada standard, if you write
>
>   a := x / y;
>
>where y is 1.0, and Machine_Overflows is false for the floating-point type in
>question, then the result is "unspecified". This means that the compiler could
>generate code to send denial-of-service-attacks to the internet root servers,
>and you would not be violating the standard, but you would not get many
>customers for your compiler. What users would expect here on an IEEE machine
>is to get infinities, even though the Ada RM says nothing about this possibility.
>
>  
>
I am not an Ada programmer, but if this is division like I think it
is, I don't understand why you would expect machine overflow by
dividing by one. Or is this a typo where you meant "where y is 0.0"?

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

[Robert Dewar]

> No, it's a compile my buggy program issue.

That's too harsh, a program that does not follow the letter of the standard may
still be perfectly valid for a given implementation, just not portable, but the
programmer may not care about portable, and may care very much whether or not a
given implementation behaves or does not behave in a particular manner.

Yes, implementors can stand on their pedastals and read the standard, and are 
entitled to do so. But potential users are also entititled to take their marbles
and go elsewhere. You have to strike a balance.

Example: Fortran-66 was carefully designed to allow the use of an Algol-60 style
stack for local variables (in particular, if you set a local variable on exit
from a procedure (e.g. a boolean First_Time_In variable) you cannot according to
the standard expect it to be set that way on the next call.

BUT, in practice all Fortran compilers used static allocation, so much so that this
was considered the "right" way of doing things. Burroughs was certainly technically
correct vis-a-vis the standard when they used a stack implementation, but virtually
all Fortran (I should write FORTRAN for 66 :-) users found their compiler useless.

There are many reasons why people would want to force the compiler to obey inlining,
and yes, they are outside the standard, but that does not necessarily make them
illegitimate. For example in GNAT we respect pragma Inline_Always (a pragma we
added for GNAT, it's not in the standard), because it is useful in various
circumstances (e.g. for avoiding this use of a runtime library in a certified
environment).

Robert Dewar

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

[Eric Christopher]

On Thu, 2003-03-13 at 15:12, Robert Dewar wrote:
> > No, it's a compile my buggy program issue.
> 
> That's too harsh, a program that does not follow the letter of the standard may
> still be perfectly valid for a given implementation, just not portable, but the
> programmer may not care about portable, and may care very much whether or not a
> given implementation behaves or does not behave in a particular manner.
> 

This is ridiculous, and absolutely unsupportable. There's no way that we
can promise the behavior that every user that decides not to program to
the various language standards will get the behavior that they expect -
not unless you have a patch to enable the compiler to read the user's
mind.

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.

-eric

-- 
o/~ got caught stealing fire from the sky o/~

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

[Olivier Galibert]

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".  For every previous version of gcc, it
meant the same thing.  Now, it suddendly means nothing at all.  So why
do you have an "inline" keyword in the first place, why was it in gcc
for C before it happened in the standard, and why your reaction when
it's eventually added to the standard is to ensure that it doesn't do
anything?

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.
But it's a QOI issue to actually have it do what's expected.  The only
reasonable discussion is whether to have -fobey-inline or
-fno-obey-inline as default.

  OG.

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

[Matt Austern]

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

			--Matt

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

[Bernd Schmidt]

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.

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

[Richard Almquist]

In the future, I think that the compiler should have a better idea about 
what should be inlined than the programmer.  Therefore, in the long run 
GCC should ignore the inline keyword.

There will also always be special situations where the programmer does 
need to be able to force the compiler to inline.  Thus there will always 
be a need for always_inline. But this should not be commonly used.

However since we are having this debate, I guess that GCC is not that 
good at inlining yet.  So I'll go away and let more knowlegable people 
figure out how to fix it.

Richard

Bernd Schmidt wrote:
> 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.
> 
> 

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

[Steven Bosscher]

Op ma 17-03-2003, om 00:30 schreef Richard Almquist:
> In the future, I think that the compiler should have a better idea about 
> what should be inlined than the programmer.  Therefore, in the long run 
> GCC should ignore the inline keyword.

Bah, how can anybody make such a claim?  "The compiler should ignore the
user input because it is smarter than the user".  Well, I'm pretty sure
none of us will be around to see that happen, if it's possible at all
without unreasonable costs.

Why? Because compilers will always be dumb piece of software, tuned by
humans to work well for most code.

Yes, a really good compiler can make the right decisions most of the
time.  But not *all* of the time!

Look again at kernel programming, or even better, at Alexandre's example
of a dynamic loader.  And those are just the very extreme examples, but
for some user code it might well be that the user sometimes has very
very good reasons to inline something when the compiler would not
normally consider that function for inlining.

Lets look at what information a compiler could use to make inline
decisions, ignoring recursive functions, functions that call alloca,
etc.:

(Correct me if I'm wrong, and I probably am ;-)
1) Size of a function (the number of instructions).  With tree
   inlining in GCC this is not a very good measure, because:
     a) It's impossible to tell how many insn per tree you,
        have, the best you can do is guestimate, and
     b) it's impossible to tell how much of the function can
        be optimized away.
   (a) may not be so bad for the old RTL inliner, but that one
   of course had its own drawbacks, and (b) still stands...

2) Effects on register pressure.  Again, hard to tell, just
   guessing is the best one can do.  GCC doesn't take this
   into account at all, it can't tell from trees obviously.

3) (can't think of other really important ones, though I guess
    there are...) 

All of these are probably true for any compiler.

Bottom line: It's just guess work, with some numbers and buttons to tune
it to work right on whatever test cases you have available.  There is
just no easy way to tell what's best for any given function.  All you
can do is find heuristics that work best for most cases.

Now back to the original statement: "The compiler will be able to ignore
the "inline" keyword."  Sorry, not true in all cases IMHO.

And *that* is why I would like to see that the final choice can be left
to the user, with -fobey-inline, or -finline-limit=kazillion or whatever
other flag/attribute/gizmo.

Greetz
Steven

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

[Andreas Schwab]

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

|> Look again at kernel programming, or even better, at Alexandre's example
|> of a dynamic loader.  And those are just the very extreme examples, but
|> for some user code it might well be that the user sometimes has very
|> very good reasons to inline something when the compiler would not
|> normally consider that function for inlining.

IMHO these are the places where __attribute__((always_inline)) is the
right fix.  When the compiler has become smart enough the case where this
is still needed should become rare.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Steven Bosscher]

Op ma 17-03-2003, om 11:47 schreef Andreas Schwab:
> Steven Bosscher <s.bosscher@student.tudelft.nl> writes:
> 
> |> Look again at kernel programming, or even better, at Alexandre's example
> |> of a dynamic loader.  And those are just the very extreme examples, but
> |> for some user code it might well be that the user sometimes has very
> |> very good reasons to inline something when the compiler would not
> |> normally consider that function for inlining.
> 
> IMHO these are the places where __attribute__((always_inline)) is the
> right fix.  When the compiler has become smart enough the case where this
> is still needed should become rare.

Hmm, I tried to make a point that there is no such thing as "smart
enough", only "smart enough for where it's tuned to be smart".  Really,
I'd love to see really a smart inlining decision algorithm, but in the
end a compiler will always just be guessing.

Now I'd love to be proven wrong.  How would you want to make the
compiler smarter, what heuristics are you thinking of here?

Also, you ignore the point that the final decision should be left with
the user.  Apparently you disagree with that?

Greetz
Steven

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

[Andreas Schwab]

Steven Bosscher <s.bosscher@student.tudelft.nl> writes:

|> Op ma 17-03-2003, om 11:47 schreef Andreas Schwab:
|> > Steven Bosscher <s.bosscher@student.tudelft.nl> writes:
|> > 
|> > |> Look again at kernel programming, or even better, at Alexandre's example
|> > |> of a dynamic loader.  And those are just the very extreme examples, but
|> > |> for some user code it might well be that the user sometimes has very
|> > |> very good reasons to inline something when the compiler would not
|> > |> normally consider that function for inlining.
|> > 
|> > IMHO these are the places where __attribute__((always_inline)) is the
|> > right fix.  When the compiler has become smart enough the case where this
|> > is still needed should become rare.
|> 
|> Hmm, I tried to make a point that there is no such thing as "smart
|> enough", only "smart enough for where it's tuned to be smart".  Really,
|> I'd love to see really a smart inlining decision algorithm, but in the
|> end a compiler will always just be guessing.

When inlining is required for reason of semantics (eg. dynamic linker
startup) you are outside the scope of the standard and always_inline is
IMHO an appropriate answer.

|> Now I'd love to be proven wrong.  How would you want to make the
|> compiler smarter, what heuristics are you thinking of here?

Time moves forward, and better algorithms will be found, just like today's
register allocators are good enough to be able to ignore the register
keyword (although some people still think they know better).

|> Also, you ignore the point that the final decision should be left with
|> the user.  Apparently you disagree with that?

always_inline gives you the control.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Steven Bosscher]

Op ma 17-03-2003, om 14:18 schreef Andreas Schwab:
> Steven Bosscher <s.bosscher@student.tudelft.nl> writes:
> |> Hmm, I tried to make a point that there is no such thing as "smart
> |> enough", only "smart enough for where it's tuned to be smart".  Really,
> |> I'd love to see really a smart inlining decision algorithm, but in the
> |> end a compiler will always just be guessing.
> 
> When inlining is required for reason of semantics (eg. dynamic linker
> startup) you are outside the scope of the standard and always_inline is
> IMHO an appropriate answer.
> 
> |> Now I'd love to be proven wrong.  How would you want to make the
> |> compiler smarter, what heuristics are you thinking of here?
> 
> Time moves forward, and better algorithms will be found, just like today's
> register allocators are good enough to be able to ignore the register
> keyword (although some people still think they know better).

For "register" you're absolutely right.  For "inline" you are not.

Register allocation algorithms have a much better theoretical foundation
than inlining algorithms do.  A register allocator does not have to
guess as much as the inliner, simply because it can be described
mathematically and because much more useful information is available by
the time you do register allocation.

Really, your "smart enough" inline algorithm is a myth.  It ain't gonna
happen.

> |> Also, you ignore the point that the final decision should be left with
> |> the user.  Apparently you disagree with that?
> 
> always_inline gives you the control.

Yes, I suppose it does, but it's less than elegant, and it's patronizing
the user.  Especially in 'C', when people use "inline" they usually mean
"inline".  Again, for C++ things may be different.

Greetz
Steven

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

[Segher Boessenkool]

Olivier Galibert wrote:
> Remember, inline was _added_ to the standard because it was considered
> useful by the users.  It's not legacy like register,

"inline" is legacy in _exactly the same way_ as "register" is:
the compiler can make a better guess as to what to inline
(cq what to put in registers) than the user can.  At least,
that's the plan.  It would be a good idea if the
compiler took "inline" (and "register") as a very strong
hint to actually inline (or put in register) -- it should
do it unless it really cannot.  The only thing that can
be hurt by the compiler obeying the user's code is
performance -- and if a user wants to write "inline"
(or "register") he/she should be aware that it will
not always improve performance.

It's very nice if the compiler can make better
decisions than the user, but it should always obey
the user.  Unless, maybe, a -fno-obey-inline-keyword flag
is given -- such a flag could help people compiling
"legacy" software sprinkled with way too many bad "inline"
(or "register") hints.

Hrm, now I find myself arguing to add the flag, but
defaulting it to off, while I thought I wanted to argue
against adding the compiler flag :-)

And it would be really great if we could have an
-fobey-register-keyword flag, too :)


Segher

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

[Andi Kleen]

Andrew Haley <aph@redhat.com> writes:

> Yeah.  I gotta admit that 
> 
> #define inline          __inline__ __attribute__((always_inline))
> 
> solves the problem so completely that an new gcc option is unnecessary.
> It can even be written "gcc -D inline=__inline__ __attribute__((always_inline))"

Actually not. First you forgot the `"'s, but even when you add them 
they are in grave danger of being eaten by various Makefiles who 
first execute a shell script or similar to run the compiler.
I had this problem with the Linux kernel Makefiles. The only thing that worked
reliable was

-include file 

in the Makefile and putting the define into file. But that's quite ugly.

-fobey-inline would be much easier.

-Andi

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

[Richard Guenther]

Andrew writes:
> Neil Booth writes:
> > Lars Segerlund wrote:-
> >
> > >  Are there any arguments against this other than ideological ? (
this
> > > flag doesn't interfere with gcc's normal operation and only when
it's
> > > needed is it in effect, how can that be so bad ? ).
> >
> > That's not a good argument for yet-another-switch-in-gcc.
>
> Yeah.  I gotta admit that
>
> #define inline          __inline__ __attribute__((always_inline))
>
>solves the problem so completely that an new gcc option is unnecessary.
>It can even be written "gcc -D inline=__inline__
>__attribute__((always_inline))"
>Andrew.

This does _not_ work for C++ - try it! You'll get the first compile errors
inside libstdc++. Make it work for C++ and I'll be happy.

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

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

[S. Bosscher]

> > On Thu, Mar 13, 2003 at 09:54:05AM +0000, Richard Earnshaw wrote:
> > > I still think this is a bad idea.  Please start thinking about
> > > how to produce a better nut cracker rather than a larger sledge 
> > > hammer.
> > 
> > -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.

You've said that many times now, and you're right.

Many GCC users have said that if they say "inline" they really mean "inline"
(e.g. linux kernel hackers).  And they don't want the compiler to say,
"well, not while I'm around!".

This compiler flag allows the user to make the decision, I don't see what's
wrong with that.

Of course the nut cracker should be fixed, but the sledge hammer will help
those users for now.

Greetz
Steven

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

[Richard Guenther]

Hi!

I finally got the patch work for C++ (see attached patch - maybe
completely bogous, though...). An I have some numbers for you:

Without -fobey-inline I get (time per iteration of the bench is displayed)

Benchmark size 32768:
  ET:               4.07126e-08
  Stencil:          3.08246e-08
  ScalarCode (int): 6.23149e-08
  ScalarCode (Loc): 2.04469e-07
Benchmark size 327680:
  ET:               4.3396e-08
  Stencil:          4.61121e-08
  ScalarCode (int): 6.61898e-08
  ScalarCode (Loc): 2.02973e-07
Benchmark size 3276800:
  ET:               4.49557e-08
  Stencil:          4.72165e-08
  ScalarCode (int): 6.81046e-08
  ScalarCode (Loc): 2.11086e-07

Note that for ScalarCode (Loc) which uses Iterator style indexing we are
about one magnitute worse than the rest.

With -fobey-inline the numbers change to:

Benchmark size 32768:
  ET:               4.19604e-08
  Stencil:          3.06718e-08
  ScalarCode (int): 3.93084e-08
  ScalarCode (Loc): 7.59901e-08
Benchmark size 327680:
  ET:               4.29627e-08
  Stencil:          4.6457e-08
  ScalarCode (int): 4.75829e-08
  ScalarCode (Loc): 8.20892e-08
Benchmark size 3276800:
  ET:               4.60333e-08
  Stencil:          4.79431e-08
  ScalarCode (int): 4.73465e-08
  ScalarCode (Loc): 8.29285e-08

Which is now much more reasonable - the optimizers can do useful work on
completely inlined code. (I used -O2 -march=athlon -fomit-frame-pointer
-funroll-loops for the rest of the options)

The patch I used is appended below.

I really would like to have something like this in 3.3!

Thanks, Richard.


Index: gcc/c-objc-common.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-objc-common.c,v
retrieving revision 1.18
diff -u -u -r1.18 c-objc-common.c
--- gcc/c-objc-common.c	25 Oct 2002 17:26:51 -0000	1.18
+++ gcc/c-objc-common.c	12 Mar 2003 21:04:52 -0000
@@ -64,7 +64,7 @@
   if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (fn)) != NULL)
     return 1;

-  return DECL_DECLARED_INLINE_P (fn) && DECL_EXTERNAL (fn);
+  return DECL_DECLARED_INLINE_P (fn) && (DECL_EXTERNAL (fn) || flag_obey_inline);
 }

 static tree
Index: gcc/flags.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/flags.h,v
retrieving revision 1.93
diff -u -u -r1.93 flags.h
--- gcc/flags.h	20 Oct 2002 19:18:29 -0000	1.93
+++ gcc/flags.h	12 Mar 2003 21:04:52 -0000
@@ -384,6 +384,11 @@

 extern int flag_rerun_loop_opt;

+/* Nonzero for -fobey-inline.  If true, the 'inline' keyword must be obeyed,
+   regardless of codesize.  */
+
+extern int flag_obey_inline;
+
 /* Nonzero means make functions that look like good inline candidates
    go inline.  */

Index: gcc/langhooks.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/langhooks.c,v
retrieving revision 1.34.4.1
diff -u -u -r1.34.4.1 langhooks.c
--- gcc/langhooks.c	19 Feb 2003 05:39:28 -0000	1.34.4.1
+++ gcc/langhooks.c	12 Mar 2003 21:04:52 -0000
@@ -300,7 +300,7 @@
   if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (fn)) != NULL)
     return 1;

-  return 0;
+  return flag_obey_inline;
 }

 /* lang_hooks.tree_inlining.add_pending_fn_decls is called before
Index: gcc/toplev.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/toplev.c,v
retrieving revision 1.690.2.12
diff -u -u -r1.690.2.12 toplev.c
--- gcc/toplev.c	10 Mar 2003 12:27:13 -0000	1.690.2.12
+++ gcc/toplev.c	12 Mar 2003 21:04:53 -0000
@@ -663,6 +663,11 @@

 int flag_rerun_loop_opt;

+/* Nonzero for -fobey-inline.  If true, the 'inline' keyword must be obeyed,
+   regardless of codesize.  */
+
+int flag_obey_inline;
+
 /* Nonzero for -finline-functions: ok to inline functions that look like
    good inline candidates.  */

@@ -1031,6 +1036,8 @@
    N_("Generate code for funcs even if they are fully inlined") },
   {"inline", &flag_no_inline, 0,
    N_("Pay attention to the 'inline' keyword") },
+  {"obey-inline", &flag_obey_inline, 1,
+   N_("Obey 'inline' keyword and always inline, regardless of size") },
   {"keep-static-consts", &flag_keep_static_consts, 1,
    N_("Emit static const variables even if they are not used") },
   {"syntax-only", &flag_syntax_only, 1,
Index: gcc/cp/tree.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/tree.c,v
retrieving revision 1.307.2.2
diff -u -u -r1.307.2.2 tree.c
--- gcc/cp/tree.c	7 Mar 2003 21:45:29 -0000	1.307.2.2
+++ gcc/cp/tree.c	12 Mar 2003 21:04:55 -0000
@@ -2239,7 +2239,8 @@
   tree fn = *fnp;

   if (flag_really_no_inline
-      && lookup_attribute ("always_inline", DECL_ATTRIBUTES (fn)) == NULL)
+      && (lookup_attribute ("always_inline", DECL_ATTRIBUTES (fn)) == NULL
+          && !(flag_obey_inline && DECL_DECLARED_INLINE_P(fn))))
     return 1;

   /* We can inline a template instantiation only if it's fully
Index: gcc/doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.209.2.17
diff -u -u -r1.209.2.17 invoke.texi
--- gcc/doc/invoke.texi	6 Mar 2003 23:35:07 -0000	1.209.2.17
+++ gcc/doc/invoke.texi	12 Mar 2003 21:04:55 -0000
@@ -272,6 +272,7 @@
 -fgcse  -fgcse-lm  -fgcse-sm -floop-optimize -fcrossjumping @gol
 -fif-conversion -fif-conversion2 @gol
 -finline-functions  -finline-limit=@var{n}  -fkeep-inline-functions @gol
+-fobey-inline @gol
 -fkeep-static-consts  -fmerge-constants  -fmerge-all-constants @gol
 -fmove-all-movables  -fnew-ra  -fno-branch-count-reg @gol
 -fno-default-inline  -fno-defer-pop @gol
@@ -3611,6 +3612,12 @@
 is declared @code{static}, nevertheless output a separate run-time
 callable version of the function.  This switch does not affect
 @code{extern inline} functions.
+
+@item -fobey-inline
+@opindex fobey-inline
+Make the @code{inline} keyword imperative; inline every function marked
+with the @code{inline} keyword, regardless of size.  Often leads to
+code bloat.

 @item -fkeep-static-consts
 @opindex fkeep-static-consts

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

[Mike Stump]

On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> I finally got the patch work for C++ (see attached patch - maybe
> completely bogous, though...). An I have some numbers for you:

If you could, find the various flags that control inlining, and bump 
the numbers up until you get similar number to (or better than) this 
flag.  Then tell us what those numbers were, then we can consider 
upping those numbers.  Also, tell us the language, I assume it was C++.

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

[Richard Guenther]

On Wed, 12 Mar 2003, Mike Stump wrote:

> On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> > I finally got the patch work for C++ (see attached patch - maybe
> > completely bogous, though...). An I have some numbers for you:
>
> If you could, find the various flags that control inlining, and bump
> the numbers up until you get similar number to (or better than) this
> flag.  Then tell us what those numbers were, then we can consider
> upping those numbers.  Also, tell us the language, I assume it was C++.

I think the problems come from the fact we dont do backwards inlining
and my code (Pooma, lots of recursive template metaprogramming) is no
good measure for general applicable inlining limits (at least in the
current gcc metric). So I suspect if we up the limits so I get decent
code, others would be seriously suffering.

But anyway - I'll try and report them.

Oh - I still like this patch or some equivalent to be included in gcc 3.3
of course ;)

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

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

[Richard Earnshaw]

> On Wed, 12 Mar 2003, Mike Stump wrote:
> 
> > On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> > > I finally got the patch work for C++ (see attached patch - maybe
> > > completely bogous, though...). An I have some numbers for you:
> >
> > If you could, find the various flags that control inlining, and bump
> > the numbers up until you get similar number to (or better than) this
> > flag.  Then tell us what those numbers were, then we can consider
> > upping those numbers.  Also, tell us the language, I assume it was C++.
> 
> I think the problems come from the fact we dont do backwards inlining
> and my code (Pooma, lots of recursive template metaprogramming) is no
> good measure for general applicable inlining limits (at least in the
> current gcc metric). So I suspect if we up the limits so I get decent
> code, others would be seriously suffering.

Backwards inlining is now possible on the trunk thanks to Jan's 
unit-at-once work.

> 
> But anyway - I'll try and report them.
> 
> Oh - I still like this patch or some equivalent to be included in gcc 3.3
> of course ;)

I still think this is a bad idea.  Please start thinking about how to 
produce a better nut cracker rather than a larger sledge hammer.

R.

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

[Richard Guenther]

On Thu, 13 Mar 2003, Richard Earnshaw wrote:

> > On Wed, 12 Mar 2003, Mike Stump wrote:
> >
> > > On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> > > > I finally got the patch work for C++ (see attached patch - maybe
> > > > completely bogous, though...). An I have some numbers for you:
> > >
> > > If you could, find the various flags that control inlining, and bump
> > > the numbers up until you get similar number to (or better than) this
> > > flag.  Then tell us what those numbers were, then we can consider
> > > upping those numbers.  Also, tell us the language, I assume it was C++.
> >
> > I think the problems come from the fact we dont do backwards inlining
> > and my code (Pooma, lots of recursive template metaprogramming) is no
> > good measure for general applicable inlining limits (at least in the
> > current gcc metric). So I suspect if we up the limits so I get decent
> > code, others would be seriously suffering.
>
> Backwards inlining is now possible on the trunk thanks to Jan's
> unit-at-once work.

I thought this did not work for C++ yet. At least I'm happy with g++ 3.3
performance now as I figured out the right knobs.

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

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

[Olivier Galibert]

On Thu, Mar 13, 2003 at 09:54:05AM +0000, Richard Earnshaw wrote:
> I still think this is a bad idea.  Please start thinking about how to 
> produce a better nut cracker rather than a larger sledge hammer.

-fobey-inline is more of a correctness issue than a performance issue
for the people who need it.

  OG.

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

[Richard Earnshaw]

> On Thu, Mar 13, 2003 at 09:54:05AM +0000, Richard Earnshaw wrote:
> > I still think this is a bad idea.  Please start thinking about how to 
> > produce a better nut cracker rather than a larger sledge hammer.
> 
> -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.

R.

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

[Andrew Haley]

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.

Andrew.

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

[Richard Earnshaw]

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

R.

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

[Lars Segerlund]

  Please, this is getting tiresome, I agree with Steven, this is needed, 
otherwise it'll be a case of 'you can't build a linux kernel without a 
patch to gcc'

  If this is not working or any similar mechanism, it will make those of 
us using this sort of functionality bear the burden of replacing large 
sections of code with macros.

  It has been repeatedly requested, and surely it's not resonable to 
argue with fx. kernel developers who says thar they REALLY need this ?

  Are there any arguments against this other than ideological ? ( this 
flag doesn't interfere with gcc's normal operation and only when it's 
needed is it in effect, how can that be so bad ? ).

  / Lars Segerlund.

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

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

[Daniel Jacobowitz]

On Thu, Mar 13, 2003 at 03:19:45PM +0100, Lars Segerlund wrote:
> 
>  Please, this is getting tiresome, I agree with Steven, this is needed, 
> otherwise it'll be a case of 'you can't build a linux kernel without a 
> patch to gcc'
> 
>  If this is not working or any similar mechanism, it will make those of 
> us using this sort of functionality bear the burden of replacing large 
> sections of code with macros.
> 
>  It has been repeatedly requested, and surely it's not resonable to 
> argue with fx. kernel developers who says thar they REALLY need this ?

For the record, the kernel doesn't need this any more.  Go check 2.5;
new versions of <linux/compiler.h> contain this line:
#define inline          __inline__ __attribute__((always_inline))

Which should accomplish the same thing.


(That said, I still think -fobey-inline is a reasonable thing to
support.)

> 
>  Are there any arguments against this other than ideological ? ( this 
> flag doesn't interfere with gcc's normal operation and only when it's 
> needed is it in effect, how can that be so bad ? ).
> 
>  / Lars Segerlund.
> 
> 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.
> >
> >R.
> >
> >
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Neil Booth]

Lars Segerlund wrote:-

>  Are there any arguments against this other than ideological ? ( this 
> flag doesn't interfere with gcc's normal operation and only when it's 
> needed is it in effect, how can that be so bad ? ).

That's not a good argument for yet-another-switch-in-gcc.

Neil.

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

[Andrew Haley]

Neil Booth writes:
 > Lars Segerlund wrote:-
 > 
 > >  Are there any arguments against this other than ideological ? ( this 
 > > flag doesn't interfere with gcc's normal operation and only when it's 
 > > needed is it in effect, how can that be so bad ? ).
 > 
 > That's not a good argument for yet-another-switch-in-gcc.

Yeah.  I gotta admit that 

#define inline          __inline__ __attribute__((always_inline))

solves the problem so completely that an new gcc option is unnecessary.
It can even be written "gcc -D inline=__inline__ __attribute__((always_inline))"
Andrew.

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

[Gabriel Dos Reis]

Lars Segerlund <lars.segerlund@comsys.se> writes:

|   Are there any arguments against this other than ideological ?

What is ideaological about attributre((always_inline))?

I guess flagging people  of being ideological ins't the best way you
could have that feature in.

-- Gaby

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

[Lars Segerlund]

  Sorry point taken :-) ...

  / Lars

Gabriel Dos Reis wrote:
> Lars Segerlund <lars.segerlund@comsys.se> writes:
> 
> |   Are there any arguments against this other than ideological ?
> 
> What is ideaological about attributre((always_inline))?
> 
> I guess flagging people  of being ideological ins't the best way you
> could have that feature in.
> 
> -- Gaby
> 

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

[Alexandre Oliva]

On Mar 14, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

> Lars Segerlund <lars.segerlund@comsys.se> writes:
> |   Are there any arguments against this other than ideological ?

> What is ideaological about attributre((always_inline))?

always_inline does have a very important use.  inline has never ever
meant `if you can't inline this, error out'.  IIRC, always_inline was
introduced to have a means to express this need.  This is actually
essential for code in say a dynamic loader's bootstrap code, in which
function calls cannot be expected to work, since it hasn't even
relocated itself yet.  I suppose some kernel code may have similar
needs as well.  Anyway, the point of always_inline is not about
inlining for performance, it's inlining for correctness.  If the
compiler turns out to be unable to inline the code, we want it to bail
out with an error, not just go ahead without inlining under the
assumption that it's funtionally-equivalent.  When you use
always_inline, it isn't.  Or at least it shouldn't be.  Whether the
implementation of always_inline has actually followed this suggestion,
and remained supporting this, I don't know.  But if it doesn't, I'd
call it a bug.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

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

[Bernd Schmidt]

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

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

[Gabriel Dos Reis]

Bernd Schmidt <bernds@redhat.com> writes:

[...]

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

In my opinion, that regression is a reason to really improve the
inlining heuristics, not a reason to add yet another switch.

GCC will get quickly out of control if for each regression we have to
add a switch to paper over the problem.

-- Gaby

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

[Bernd Schmidt]

On 15 Mar 2003, Gabriel Dos Reis wrote:

> Bernd Schmidt <bernds@redhat.com> writes:
> 
> [...]
> 
> | 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.
> 
> In my opinion, that regression is a reason to really improve the
> inlining heuristics, not a reason to add yet another switch.
> 
> GCC will get quickly out of control if for each regression we have to
> add a switch to paper over the problem.

I can do fine without the switch.  I just want the old behaviour back.


Bernd

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

[Mike Stump]

On Saturday, March 15, 2003, at 07:51 AM, Gabriel Dos Reis wrote:
> | 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.
>
> In my opinion, that regression is a reason to really improve the
> inlining heuristics, not a reason to add yet another switch.

It is obvious that for C, we should increase the limits.  We should 
increase them until such time as half of the people are complaining 
they are too high, and half are complaining that they are too small.  
At that point, we really need to qualitatively improve if people are 
still complaining.  I had them up at 10000 or some such number, then it 
was dropped way down, 300 or so...  Time to bounce it back up.

[ yes, I know just how, uhm, pragmatic, this is. ]

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

[Richard Guenther]

On Wed, 12 Mar 2003, Mike Stump wrote:

> On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> > I finally got the patch work for C++ (see attached patch - maybe
> > completely bogous, though...). An I have some numbers for you:
>
> If you could, find the various flags that control inlining, and bump
> the numbers up until you get similar number to (or better than) this
> flag.  Then tell us what those numbers were, then we can consider
> upping those numbers.  Also, tell us the language, I assume it was C++.

Ok, the solution for me is simple - just disable decay of
max-inline-insns-single by f.i. setting max-inline-insns to 1000000
or max-inline-slope to 1000000 (both just artificial high numbers). For
some reasons the latter produces better results, I dont know why.

One could find smaller values for my particular testcase, but this wouldnt
cure the problem in general I think, so maybe an extra switch to disable
the inlining limits decay would be useful?

Just one more point, upping this limit does have some negative impact on
compiling performance:

bellatrix:~/src/pooma-bib/r2/benchmarks/test$ g++-3.3
/net/bellatrix/home/rguenth/src/pooma-bib/r2/benchmarks/test/Bench.cpp -o
/net/bellatrix/home/rguenth/src/pooma-bib/r2/benchmarks/test/LINUXgcc/Bench
-ftemplate-depth-60 -fno-exceptions  -Drestrict=__restrict__ -DNOPAssert
-DNOCTAssert -I/home/rguenth/src/pooma-bib/r2/src
-I/home/rguenth/src/pooma-bib/r2/lib/LINUXgcc
-L/home/rguenth/src/pooma-bib/r2/lib/LINUXgcc -lpooma -lm -O2
-march=athlon -fomit-frame-pointer -funroll-loops -ftime-report

Execution times (seconds)
 garbage collection    :   1.88 ( 8%) usr   0.00 ( 0%) sys   2.25 ( 7%)
 cfg construction      :   0.11 ( 0%) usr   0.01 ( 1%) sys   0.12 ( 0%)
 cfg cleanup           :   0.28 ( 1%) usr   0.01 ( 1%) sys   0.32 ( 1%)
 trivially dead code   :   0.34 ( 1%) usr   0.00 ( 0%) sys   0.38 ( 1%)
 life analysis         :   0.49 ( 2%) usr   0.00 ( 0%) sys   0.56 ( 2%)
 life info update      :   0.13 ( 1%) usr   0.00 ( 0%) sys   0.13 ( 0%)
 preprocessing         :   0.49 ( 2%) usr   0.20 (10%) sys   0.71 ( 2%)
 lexical analysis      :   0.41 ( 2%) usr   0.17 ( 9%) sys   0.72 ( 2%)
 parser                :   5.27 (21%) usr   0.53 (27%) sys   6.28 (21%)
 name lookup           :   2.98 (12%) usr   0.82 (41%) sys   4.12 (14%)
 expand                :   2.74 (11%) usr   0.01 ( 1%) sys   3.49 (12%)
 varconst              :   0.10 ( 0%) usr   0.01 ( 1%) sys   0.12 ( 0%)
 integration           :   1.24 ( 5%) usr   0.03 ( 2%) sys   1.41 ( 5%)
 jump                  :   0.23 ( 1%) usr   0.01 ( 1%) sys   0.27 ( 1%)
 CSE                   :   2.19 ( 9%) usr   0.03 ( 2%) sys   2.46 ( 8%)
 global CSE            :   0.72 ( 3%) usr   0.02 ( 1%) sys   0.80 ( 3%)
 loop analysis         :   0.54 ( 2%) usr   0.00 ( 0%) sys   0.59 ( 2%)
 CSE 2                 :   0.85 ( 3%) usr   0.01 ( 1%) sys   0.95 ( 3%)
 branch prediction     :   0.28 ( 1%) usr   0.00 ( 0%) sys   0.38 ( 1%)
 flow analysis         :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%)
 combiner              :   0.29 ( 1%) usr   0.01 ( 1%) sys   0.40 ( 1%)
 if-conversion         :   0.11 ( 0%) usr   0.00 ( 0%) sys   0.12 ( 0%)
 regmove               :   0.10 ( 0%) usr   0.01 ( 1%) sys   0.15 ( 0%)
 mode switching        :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%)
 local alloc           :   0.29 ( 1%) usr   0.02 ( 1%) sys   0.32 ( 1%)
 global alloc          :   0.59 ( 2%) usr   0.00 ( 0%) sys   0.62 ( 2%)
 reload CSE regs       :   0.48 ( 2%) usr   0.00 ( 0%) sys   0.49 ( 2%)
 flow 2                :   0.06 ( 0%) usr   0.00 ( 0%) sys   0.15 ( 0%)
 if-conversion 2       :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%)
 peephole 2            :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.09 ( 0%)
 rename registers      :   0.21 ( 1%) usr   0.00 ( 0%) sys   0.23 ( 1%)
 scheduling 2          :   0.54 ( 2%) usr   0.05 ( 3%) sys   0.65 ( 2%)
 reorder blocks        :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
 shorten branches      :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.11 ( 0%)
 reg stack             :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
 final                 :   0.12 ( 0%) usr   0.02 ( 1%) sys   0.14 ( 0%)
 rest of compilation   :   0.38 ( 2%) usr   0.02 ( 1%) sys   0.45 ( 2%)
 TOTAL                 :  24.77             1.99            30.15

bellatrix:~/src/pooma-bib/r2/benchmarks/test$ g++-3.3
/net/bellatrix/home/rguenth/src/pooma-bib/r2/benchmarks/test/Bench.cpp -o
/net/bellatrix/home/rguenth/src/pooma-bib/r2/benchmarks/test/LINUXgcc/Bench
-ftemplate-depth-60 -fno-exceptions  -Drestrict=__restrict__ -DNOPAssert
-DNOCTAssert -I/home/rguenth/src/pooma-bib/r2/src
-I/home/rguenth/src/pooma-bib/r2/lib/LINUXgcc
-L/home/rguenth/src/pooma-bib/r2/lib/LINUXgcc -lpooma -lm -O2
-march=athlon -fomit-frame-pointer -funroll-loops --param
max-inline-slope=1000000 -ftime-report

Execution times (seconds)
 garbage collection    :   2.58 ( 8%) usr   0.01 ( 0%) sys   2.62 ( 8%)
 cfg construction      :   0.15 ( 0%) usr   0.02 ( 1%) sys   0.16 ( 0%)
 cfg cleanup           :   0.40 ( 1%) usr   0.03 ( 1%) sys   0.45 ( 1%)
 trivially dead code   :   0.53 ( 2%) usr   0.00 ( 0%) sys   0.57 ( 2%)
 life analysis         :   0.66 ( 2%) usr   0.00 ( 0%) sys   0.70 ( 2%)
 life info update      :   0.20 ( 1%) usr   0.00 ( 0%) sys   0.21 ( 1%)
 preprocessing         :   0.44 ( 1%) usr   0.20 ( 7%) sys   0.73 ( 2%)
 lexical analysis      :   0.46 ( 1%) usr   0.22 ( 8%) sys   0.65 ( 2%)
 parser                :   5.41 (17%) usr   0.82 (30%) sys   6.31 (18%)
 name lookup           :   2.84 ( 9%) usr   0.63 (23%) sys   3.56 (10%)
 expand                :   4.43 (14%) usr   0.22 ( 8%) sys   4.69 (14%)
 varconst              :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%)
 integration           :   2.01 ( 6%) usr   0.17 ( 6%) sys   2.18 ( 6%)
 jump                  :   0.39 ( 1%) usr   0.01 ( 0%) sys   0.40 ( 1%)
 CSE                   :   2.95 ( 9%) usr   0.03 ( 1%) sys   3.02 ( 9%)
 global CSE            :   0.95 ( 3%) usr   0.03 ( 1%) sys   1.00 ( 3%)
 loop analysis         :   0.86 ( 3%) usr   0.08 ( 3%) sys   0.96 ( 3%)
 CSE 2                 :   1.35 ( 4%) usr   0.00 ( 0%) sys   1.36 ( 4%)
 branch prediction     :   0.37 ( 1%) usr   0.01 ( 0%) sys   0.38 ( 1%)
 flow analysis         :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%)
 combiner              :   0.40 ( 1%) usr   0.00 ( 0%) sys   0.44 ( 1%)
 if-conversion         :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%)
 regmove               :   0.16 ( 1%) usr   0.00 ( 0%) sys   0.14 ( 0%)
 mode switching        :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%)
 local alloc           :   0.48 ( 2%) usr   0.00 ( 0%) sys   0.48 ( 1%)
 global alloc          :   0.65 ( 2%) usr   0.01 ( 0%) sys   0.67 ( 2%)
 reload CSE regs       :   0.56 ( 2%) usr   0.03 ( 1%) sys   0.61 ( 2%)
 flow 2                :   0.08 ( 0%) usr   0.03 ( 1%) sys   0.10 ( 0%)
 if-conversion 2       :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%)
 peephole 2            :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.05 ( 0%)
 rename registers      :   0.20 ( 1%) usr   0.00 ( 0%) sys   0.21 ( 1%)
 scheduling 2          :   0.61 ( 2%) usr   0.07 ( 3%) sys   0.65 ( 2%)
 machine dep reorg     :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%)
 shorten branches      :   0.08 ( 0%) usr   0.01 ( 0%) sys   0.09 ( 0%)
 final                 :   0.09 ( 0%) usr   0.02 ( 1%) sys   0.13 ( 0%)
 symout                :   0.00 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%)
 rest of compilation   :   0.57 ( 2%) usr   0.03 ( 1%) sys   0.59 ( 2%)
 TOTAL                 :  31.21             2.69            34.45


Hope this helps the decision.

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

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

[Richard Guenther]

On Wed, 12 Mar 2003, Mike Stump wrote:

> On Wednesday, March 12, 2003, at 01:07 PM, Richard Guenther wrote:
> > I finally got the patch work for C++ (see attached patch - maybe
> > completely bogous, though...). An I have some numbers for you:
>
> If you could, find the various flags that control inlining, and bump
> the numbers up until you get similar number to (or better than) this
> flag.  Then tell us what those numbers were, then we can consider
> upping those numbers.  Also, tell us the language, I assume it was C++.

One more datapoint - for my particular testcase the crossover from
bad to good performance is somewhere between --param max-inline-insns
30000 and 40000. But this looks artificially high for a default value
(this shows the gcc metric of insns is not very good here).

Richard.

--
Richard Guenther <richard.guenther@uni-tuebingen.de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/