This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: g++ memory bug.
- To: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Subject: Re: g++ memory bug.
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 22 Mar 1999 01:47:18 -0700
- cc: mrs at wrs dot com (Mike Stump), Jose dot Gomes at sophia dot inria dot fr, egcs-patches at cygnus dot com, mark at markmitchell dot com
- Reply-To: law at cygnus dot com
In message <199901211127.MAA08732@mururoa.inria.fr>you write:
> 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.
Could send a separate patch to fix the parenthesis error? There's no
reason we can't fix that now while we hash out the issues for -finlin-limit.
> Side note: it is claimed that these are overriden for RISC machines but I
> cannot find any such thing. Was it planned or abandonned ?
I don't think anyone ever bothered. I suspect that bumping the limit would
be a reasoanble thing to do for some targets.
Consider the PA8000 machines; they've got icache bandwidth to burn, aggressive
inlining and loop unroling are more likely to be a win on this class of
machines because these machines because the icache is not the critical
resource.
> 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.
I don't necessarily think we want to behave like the current scheme.
> 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.
That's a little more complicated than I think we want/need at this
time. One of the difficulties with developing & using gcc is the large
number of options. Luckily most are independent. If you tie in the
"maximum function size" calculation to the -Ox value, then you're
adding additional dependencies that are hard for developers to track and
often difficult for users to understand.
Thus my preference for a simple scale factor to apply to the value of
-finline-limit for functions which are marked with the inline hint.
jeff