Re: g++ memory bug.

[Jeffrey A Law <law at cygnus dot com>]

  In message <199901121312.OAA18612@mururoa.inria.fr>you write:
  > mrs@wrs.com said:
  > > The doc would need to be very more specific about this option what it
  > > does and doesn't do, and when it applies and what does 1 mean, what
  > > does 100 mean?
  > 
  > I think that explaining the current meaning of -finline-limit-n as
  > implemented in the proposed patch would be rather obscure.
Agreed.  And this is an important issue to consider.  Particularly for flags
we make available to users.

If we can not document in some reasonable fashion, then we've probably got
a bad interface :-)  However, I think we probably can describe the
multiplicative factor in a reasonable way if we try.


  > Actually, I was wondering 
  > why applying a multiplicative factor to maxinsns instead of directly
  > specifying an absolute value.
I do not know for sure either.  But I can speculate.

The more arguments that are passed to the inlined function, the more info the
compiler will have about the inline function, which in turn means more
optimization opportunties.


  > Then -finline-limit-n will have a clear meaning and default value.
  > 
  > The remaining questions are:
  > 
  > - What to do in the -Os case ?
-finline-limit-n would be an override regardless of the -Os switch.  I think
that makes the most sense.

We should note in the documentation what the default value is when -Os is
in effect.  We should have done this when we introduced the -Os flag.  An
oversight.


  > - Can I modify the macro safely (it seems to be used only in integrate.c
  >   AFAICT).
Yes.

  > - Do we have to limit this only to functions explicitly marked as 
  >   inline (I count methods defined in the class declarations as such) ?
I'd make it a limit on any and all inlining, regardless of whether or not the
function is marked inline.  We'd need to change the proposed docs accordingly.


  > definition in c++). n is the size of functions that can be inlined in 
  > number of instructions (not counting parameter handling). 
"in roughly the number of instructions".

We can't really predict with good accuracy early in the compilation process
how big the function will be.

  > The default value of n is 64.
"except when optimizing for space where the default value of n is one.

You also need to use texi formatting macros.  @samp{n} to refer to a variable
for example.

  > (which presumably means slower programs).
I'd just leave this fragment out of the user documentation.

If we go with the scale factor, we could describe it to the user as a scale
factor which roughly corresponds to the maximum number of insns allowed in
the integrated function.

jeff