This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Inlining fails on very simple code
- From: Bernard Dautrevaux <Dautrevaux at microprocess dot com>
- To: 'Peter Barada' <pbarada at mail dot wm dot sps dot mot dot com>, degger at fhm dot edu
- Cc: aoliva at redhat dot com, gcc at gcc dot gnu dot org
- Date: Wed, 12 Dec 2001 17:53:34 +0100
- Subject: RE: Inlining fails on very simple code
> -----Original Message-----
> From: Peter Barada [mailto:pbarada@mail.wm.sps.mot.com]
> Sent: Wednesday, December 12, 2001 4:37 PM
> To: degger@fhm.edu
> Cc: aoliva@redhat.com; gcc@gcc.gnu.org
> Subject: Re: Inlining fails on very simple code
>
>
>
> >And it also says:
> >"Defining inline functions (as fast as macros)."
> >which is simply not true because I cannot force gcc to inline
> >the function without increasing the general limit which I cannot
> >afford while with macros (although ugly) I can exactly control
> >which code I'd like to have expanded where. Maybe we can
> introduce some
> >__attribute__ ((i_really_want_this_inline)) to get the desired effect
> >of finegrained control if the compiler cannot be made clever enough
> >to even catch simple and obvious win cases.
>
> From section 4.32 of the documentation (version 2.95):
>
> If you specify both 'inline' and 'extern' in the fuction definition,
> then the definition used only for inlining. In no case is the
> function compiled on its own, not even if you refer to its address
> explicitly. Such an address becomes an external reference, as if you
> had only declared the function, and had not defined it.
True, but that does not help FORCING gcc to inline the function: if it can't
inline it it generates it, but never emit the code but expect that some
magic was used to have it emit elsewhere like compiling just the extern
inline declaration after #defining inline as empty :-)
In fact I think the problem is that one parameter (max-inline-insns) is used
for two purposes:
1) Limiting the size of functions the compiler will decide *by itself* to
inline (that is functions that were NOT declared as inline, but nevertheless
expanded inline as this seems beneficial). For this use we must keep a
reasonably low value for max-inline-insns or we get uncontrolled code bloat.
2) Limiting the absolute size of any inline function. In fact here I think
GCC is trying to be smarter than the programmer: even while the programmer
says that he wants the function to be inlined, GCC thinks it knows better
and refuse to do it if the function is bigger than max-inline-insns.
IMHO use (1) is a Good Thing (TM) while (2) is at least debatable; if we
think it's needed then we should have two parameters:
max-automatic-inline-insns, that would take care of case (1), while
max-inline-insns will be used for case (2). In this case I would suggest
keeping the actual max-inline-insns default for max-automatic-inline-insns
and use a much bigger default for max-inline-insns.
This would in fact bring what was expected: by default only small enough
functions are auto-inlined but only very big/complex one can't be; and we
can adjust both limits, takeing into account the fact that an explicit
"inline" keyword, if used, indicates the programmer expect inlining to be a
win.
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------