This is the mail archive of the 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]
Other format: [Raw text]

Re: PATCH RFA: Use vectors in the C++ frontend

Jason Merrill <> writes:

> How much benefit do we get from explicitly freeing gc vectors?

I don't know, but is there any reason that we shouldn't?  I'm only
freeing the vectors after the CALL_EXPR node has been generated, so they
are no longer needed.

> Why assume that a parenthesized expression list will have 16 elements?
> I would expect most to be shorter than that.  Does this give better
> performance than just starting with a NULL vec or with 4 elements
> (i.e. the default allocation when growing from 0)?

Since the vectors are reused, they will tend to grow to the maximum
required size in a large program.  Since they are reused, we shouldn't
have too many of them.  So I started them large to avoid reallocation
costs.  Starting them at 0 won't work since that would give me NULL
which would mean confusing between "new char" and "new char()".  But I
could start them at 4.

> It seems like we could use a "return a new vec containing this one
> tree" function.

True.  I can add that.

> Also a function to build a call from a vec, rather than have to use
> _array and explicitly pull out the length and elements each time.

I suppose, although that seems sort of minor to me.

> The first_arg business is to avoid allocating a vec when we're only
> dealing with one argument?  It seems to complicate the logic
> significantly.

No.  first_arg is there because of code like add_candidates, where we
want to use the same vector of arguments with a different first argument
in different cases.  If I didn't use a separate first_arg field, then I
would have to copy the vector, which would negate some of the memory


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