This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: g++ memory bug.



  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]