Re: g++ memory bug.

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

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. I do not think there will be an easy 
way to explain what it does the way it is implemented. Actually, I was wondering 
why applying a multiplicative factor to maxinsns instead of directly specifying an 
absolute value. However, since I do not understand the gcc internals well enough I 
tried to modify your patch as little as possible.

Please comment the following proposal, which seems better to me:

Replace the line the macro INTEGRATE_THRESHOLD 

#define INTEGRATE_THRESHOLD(DECL) \
  (optimize_size \
   ? (1 + (3 * list_length (DECL_ARGUMENTS (DECL)) / 2)) \
   : (8 * (8 + list_length (DECL_ARGUMENTS (DECL)))))

By:

#define INTEGRATE_THRESHOLD(DECL, NINSNS) \
  (optimize_size \
   ? (1 + (3 * list_length (DECL_ARGUMENTS (DECL)) / 2)) \
   : (NINSNS + 8 * list_length (DECL_ARGUMENTS (DECL))))

Of course the name inline_limit_factor should change.. But I keep it 
for now.

Then replace the code fragment:

  int max_insns = INTEGRATE_THRESHOLD (fndecl);
  register int ninsns = 0;
  register tree parms;
  rtx result;

  /* We place a limit on even functions marked as inline.  */
  if (DECL_INLINE (fndecl))
    max_insns *= inline_limit_factor;

By:

  int max_insns = INTEGRATE_THRESHOLD (fndecl,64);
  register int ninsns = 0;
  register tree parms;
  rtx result;

  /* We place a limit on even functions marked as inline.  */
  if (DECL_INLINE (fndecl))
    max_insns = INTEGRATE_THRESHOLD (fndecl,inline_limit_factor);

This way the -finline-limit-n will specify the maximum size (in 
instruction number) of inlined functions not counting parameter 
handling. The default value of n would be 64 to be comprehensive
with what is done for normal functions.

Then -finline-limit-n will have a clear meaning and default value.

The remaining questions are:

- What to do in the -Os case ?
- Can I modify the macro safely (it seems to be used only in integrate.c AFAICT).
- Do we have to limit this only to functions explicitly marked as 
  inline (I count methods defined in the class declarations as such) ?

Then the documentation would be something like:

@item -finline-limit-@var{n}
By default, gcc limits the size of functions that can be inlined. This flag allows
the control of this limit for functions that are explicitly marked as inline
(ie marked with the inline keyword or defined within the class 
definition in c++). n is the size of functions that can be inlined in 
number of instructions (not counting parameter handling). The default value
of n is 64. Increasing this value can result in more inlined code at the cost
of compilation time and memory consumption. Decreasing usually makes the
compilation faster and less code will be inlined (which presumably 
means slower programs). This option is particularly useful for programs that 
use inlining heavily such as those based on recursive templates with c++.

Comments please ?

> It applies only to `inline' keyword functions (by default, class
> member functions defined within the class body are `inline' see
> -f...), and it applies to on wether a function can be inlined, before
> inlining, not after.

Oups, I actually did not really understood all the details of your change.
In particular, I did not understood that function_cannot_inline_p can also 
be called for functions not marked somehow with inline.
This shows how dumb I am when it relates to gcc's internals. :-(

> 1 means, the normal inlining limit for noninline functions that do not
> have `inline' (in your code).  Maybe one should mean something else? I
> can't help but think maybe we want less aggressive inlining, 0.1
> maybe.  Maybe /10 so that 10 means the normal limit, and 1 mean 1/10
> the normal limit? 

The above proposal (if not brain damaged) would solve these questions.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------