C++ inlining (request for better optimization).

C++ inlining (request for better optimization).

[Sergei Organov]

The progress in 'egcs' development is really exciting, thanks to all
involved. One thing, however, bothers me: it seems 'g++' could do 
better function inlining:

> cat inline.cc
class A {

public:
  A() {}
  A(const A& a) { copy(a); }

private:
  char data[10];

  void copy(const A& a) {
    for(int i = 0; i < 10; ++i)
      data[i] = a.data[i];
  }

};

A foo() {
  A a;
  A a1(a);
  return a1;
}

> g++ -c -O6 -Wall -Winline inline.cc
inline.cc: In method `A::A(const class A &)':
inline.cc:10: warning: can't inline call to `void A::copy(const class A
&)'
inline.cc:5: warning: called from here

Such behavior forces me to arrange code according to the 'egcs'
preferences 
instead of style (moving body of 'copy' before the call solves the
problem).

Maybe this behavior is intended to force programmer to move function 
definitions out of class declaration?

Is it possible to fix that?

Thanks in advance.

Sergei Organov.

Re: C++ inlining (request for better optimization).

[Joe Buck]

> The progress in 'egcs' development is really exciting, thanks to all
> involved. One thing, however, bothers me: it seems 'g++' could do 
> better function inlining:

Yes, in examples that require two or more levels of lookahead inlining
can fail: if an inline function includes another inline function that
appears later, inlining usually fails.

> Such behavior forces me to arrange code according to the 'egcs'
> preferences 
> instead of style (moving body of 'copy' before the call solves the
> problem).

An alternative to putting private before public members is something
like this:

class foo {
public:
	// foo calls private inline message 'init'
	inline foo(unsigned n);
private:
	void init(unsigned n) {
		for (int i = 0; i < n; i++)
			data[i] = i;
	}
	...
};

inline foo::foo(unsigned n) { init(n);}

> Maybe this behavior is intended to force programmer to move function 
> definitions out of class declaration?

I think it's kind of an accident caused by the order that g++ scans
the code.

> Is it possible to fix that?

Anything's possible.  However, if the fix is to make multiple passes
over the source, thereby slowing down compilation, I'd rather do -Winline
and rearrange my code.  I don't think it should be a high priority.

Re: C++ inlining (request for better optimization).

[Sergei Organov]

Joe Buck (jbuck@synopsys.com) wrote:

[...skip...]

> Yes, in examples that require two or more levels of lookahead inlining
> can fail: if an inline function includes another inline function that
> appears later, inlining usually fails.

Is there any reason for that but current 'g++' inlining implementation?

[...skip...]

> > Is it possible to fix that?
> 
> Anything's possible.  However, if the fix is to make multiple passes
> over the source, thereby slowing down compilation, I'd rather do -Winline
> and rearrange my code.  I don't think it should be a high priority.

I don't understand why multiple passes are required. Consider:

inline void g();
inline void f() {
  ...
  g();
  ...
}
inline void g() {
  ...
}

void foo() {
  g(); // 'g' is inlined
  f(); // 'f' is inlined but 'g' isn't
}

It seems that at the point of call to 'f' compiler already has enough 
information to inline call to 'g' inside inlined 'f'.

Anyway, I posted that in hope that it's relatively simple to change for 
somebody who is familiar with 'g++' inlining code. And sure, it's not 
a high priority. However, I think for C++ (as opposed to C) it's natural
to inline functions independently of body appearance because inside
class 
declaration functions may appear in any order and compiler should scan
for
the function declaration/definition up to the end of class declaration
to 
resolve call to the function anyway, isn't it?

Am I missing something?

Sergei Organov.

Re: C++ inlining (request for better optimization).

[Jason Merrill]

The reason it doesn't work like you want it to work is that inlining is
done at function definition time.  If f() uses g(), g() must be defined
before f() is defined if it is to be inlined, so that its RTL can be
inserted into the RTL for f.  It sounds like you expect inlining to be done
on a level closer to the source code, so that when someone inlines f() they
encounter the call to g() and go inline that, but it doesn't work that way
in gcc.  RTL is too low-level for that.

It would certainly be possible to do things the way you would like, but it
would probably involve throwing away the current inlining code and starting
over, and is therefore unlikely to happen any time soon.

Jason

Re: C++ inlining (request for better optimization).

[Gabriel Dos Reis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

>>>>> «Jason», Jason Merrill <jason@cygnus.com> écrit :

Jason> The reason it doesn't work like you want it to work is that inlining is
Jason> done at function definition time.  If f() uses g(), g() must be defined
Jason> before f() is defined if it is to be inlined, so that its RTL can be
Jason> inserted into the RTL for f.  It sounds like you expect inlining to be done
Jason> on a level closer to the source code, so that when someone inlines f() they
Jason> encounter the call to g() and go inline that, but it doesn't work that way
Jason> in gcc.  RTL is too low-level for that.

	Anyway, can we hope it'll happen in the future ?

-- Gaby
Gabriel Dos Reis                    | École Normale Supérieure de Cachan
INRIA, Unité de Recherche de        | Centre de Mathématiques et de Leurs
Sophia Antipolis                    |          Applications
Projet SAFIR                        |       Équipe de Géométrie 

Re: C++ inlining (request for better optimization).

[Jason Merrill]

>>>>> Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> writes:

> 	Anyway, can we hope it'll happen in the future ?

The distant future, yes.

Jason

Re: C++ inlining (request for better optimization).

[Joel Sherrill]

On 29 Nov 1997, Jason Merrill wrote:

> >>>>> Gabriel Dos Reis <Gabriel.Dos-Reis@dptmaths.ens-cachan.fr> writes:
> 
> > 	Anyway, can we hope it'll happen in the future ?
> 
> The distant future, yes.

FWIW this optimization will help languages besides C++.  Ada programs can
depend just as heavily on inlining.  This same optimization has been
mentioned in the gnat user discussions.  

--joel
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985