This is the mail archive of the
mailing list for the GCC project.
Re: g++ memory bug.
- To: mrs at wrs dot com (Mike Stump)
- Subject: Re: g++ memory bug.
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 22 Mar 1999 01:41:27 -0700
- cc: Jose dot Gomes at sophia dot inria dot fr, Theodore dot Papadopoulo 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 <199901211433.GAA15311@kankakee.wrs.com>you write:
> > To: firstname.lastname@example.org (Mike Stump)
> > Date: Thu, 21 Jan 1999 01:23:58 -0700
> > From: Jeffrey A Law <email@example.com>
> > 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?
> If a tree was marked with DECL_INLINE, we didn't hit:
> if (!DECL_INLINE (fndecl) && get_max_uid () > max_insns)
> return "function too large to be inline";
> in integrate.c. My change is to place a limit even on those, but that
> limit isn't the normal `small' (64) limit, but rather, a larger, more
> a reasonableness (<10000) test. We could place a small limit on those
> to be symmetrical with the normal case, but that is then a decision to
> be different, and I just want to ensure it is a decision and not an
> accident. I can't claim to have thought long and hard about it, so by
> default, I'm in preserve old semantics mode.
So? I don't see that as a major issue.
I think a lot of this falls back on the "what does the inline keyword mean"
question. It's a hint. Allowing users to control the size of functions
which are marked inlined seems quite reasonable to me.
> If you want inline to be more of a hint from the user and less of a
> semantic with meaning, then so limiting it (smaller) is a good change.
That's precisely how I've always seen inline -- as a hint.
I guess we were talking at different levels -- I was thinking there was
an objection to the concept of allowing a user to limit the size of a
function which will be inlined, even though it's marked as inline.
It sounds more like we're trying to determine if the same limit should
apply to both functions marked as "inline" and to those which are inlined
The existance of an "inline" hint should probably carry some weight when
determining the size limit for function inlining.
So I think we pick something, relatively arbitrary and document how the
inline hint effects the computation of when a function is too big to inline.
Limit automatic inlining to functions which are smaller than N insns and limit
inlining of functions declared as inline to X*N insns.
Where X is our scale factor. 2, 8, 10, whatever we determine is a reasonable