Re: g++ memory bug.

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

>   In message <199901181801.KAA09621@kankakee.wrs.com>you write:
>   > This is a departure from the semantics that gcc had in the past. I
>   > didn't want to depart from those semantics without a very good reason.
>   > In the absense of such a reason, I don't think we should, so that we
>   > retain as much the sameness of gcc as we can.  Could you say more on
>   > why this is the right decision?
> What particular semantics are you talking about?

	Since I had a close look at it when trying to do the patch, I 
think I can answer this question. The current semantics can be 
described with a four entry table:

	 	inline marked          Functions
                  functions         not marked inline

-Os              no limit            small limit

-O[^s]           no limit            large limit

Limits are on the size of the function.
small limit and high limit are given by the macro INTEGRATE_THRESHOLD:

Small limit is 1+(3*n_args)/2 (due to a parenthesis error in 
INTEGRATE_THRESHOLD it is currently 1+3*(n_args/2) which penalizes
one parameter functions.

Large limit is 64+8*n_args.

Side note: it is claimed that these are overriden for RISC machines but I 
cannot find any such thing. Was it planned or abandonned ?

Now we have to set a default limit. In order to behave like the 
current scheme, this limit has to be high to match the current lack 
of limit for inline marked functions. Should we apply this limit to 
non-inline marked functions we will start to inline many functions
not marked as inline in the -Os case (this is also true to a lesser
extent in the -O[^s] case). In the -Os case, this will be increase 
the size of the code and would be problematic (IMHO). I guess this is
the first change of semantics that Mike refers to.

Of course, we could make the different -O[s0-9] options to set 
different default values for the inline limit to limit this 
effect. Personnaly, I'm in favor of this (with subsequent calls to 
-finline-limit overriding the default value) provided that the
rule is simple enough.

Finally, it is important to note that if we treat non-inline marked 
functions just like inline marked ones, we totally ignore the 
programmer hint that states that particular functions have to be 
inlined more than the other ones (presumably this is done after a 
carefull analysis :-) ). This would be a second change in semantics
(specifying a function as inline or not will not change the compiler's
behaviour).

Thus, the version 2 patch I proposed (Not yet perfect, in particular does 
not correct the parenthesis problem in INTEGRATE_THRESHOLD, in the 
way I put the ChangeLog, ...), makes -finline-limit to apply only to inline
marked functions keeping the current thresholds for non-inline marked ones.
The actual limit is adjusted for parameter handling (ie we use
inline_limit+8*n_args) and the default value of inline_limit is high 
(10000) to match the actual no limit of egcs. In my preferred 
version, the default value would depend on the -O[0-9s] flag but 
again this will be a change in the current behaviour of the 
compiler... Comments ??

If a user wants to see a function to be inlined it has to mark it as 
such, and eventually increase the inline-limit (assuming of course 
that no other reason will prevent the inlining).

Overall, the current scheme seems reasonnable (apart from the memory 
explosion). I agree that the rules are a little complex and that we can
discuss them but I'm not sure that we can come up with something 
simpler and more effective.

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