Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Mon, 2 January 2006 19:49:06 +0100, Arjan van de Ven wrote:
> 
> > I'd be reluctant to trust gcc-4 to do the right thing in all cases.  If the
> > compiler fails to inline functions in certain critical cases we'll suffer
> > some performance loss and the source of that performance loss will be
> > utterly obscure.
> 
> yet.. turning inline into a hint (which causes gcc to greatly bias
> towards inlining without making it absolute) was also opposed by either
> you or Linus. Forcing is ALSO wrong. For example it causes gcc to do
> inlining even for functions that use variable sized arrays ;(

I believe your example is a non-issue by Linus' terms.  AFAIR, he
always considered variable sized arrays a bug, when used for kernel
code.  Line of argument is something like this:

o If a variable-sized array has an unknown upper bound, the stack
  will explode.
o If the upper bound is well-known, using a fixed-size array works
  just as well.
o make checkstack is unable to interpret the function preamble in
  presence of alloca() or variable sized arrays.

The last point is from irc today, not from Linus.


Interestingly, Linus and Ingo/you are arguing similarly:

Linus: I don't want to allow sloppiness.  If you know the upper bound,
I force you to write it down explicitly by using a fixed-size array.

Ingo: I don't want to allow sloppiness.  Either the inline is required
and shall be written as always_inline, or it is not and should be
removed.

Disallowing sloppiness might be a good idea in both cases.  Along
those lines, "inline" is quite seductive to over-use by sloppy
developers.  "always_inline" or "in_this_rare_case_inline_makes_sense"
would at least force sloppy people to get second thoughts.

Jörn

-- 
Good warriors cause others to come to them and do not go to others.
-- Sun Tzu