This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]