This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tree-ssa-operands.c: Use VEC instead of VARRAY.
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 04 May 2005 13:58:42 -0400
- Subject: Re: [patch] tree-ssa-operands.c: Use VEC instead of VARRAY.
- References: <email@example.com>
On Wed, 2005-05-04 at 13:40, Kazu Hirata wrote:
> Attached is a patch to use VEC instead of VARRAY.
> Andrew, AFAICT, these vectors are work areas while we are building
> operand cache, but you seem to empty these vectors when you need them,
> not when you are done with them. I *think* these can be allocated on
> heap, but could you confirm this for me?
They are not work vectors. They are a cache for the potentially long
strings of virtual operands that are added at call sites. They can last
for the duration of the operand cache, so they could be xmalloc'd.
When we are adding virtual operands, we first check to see if we have a
If we don't, we build the operands and fill the cache with the operands
that were added.
If we do have a valid cache, then we simply copy them directly to the
build vectors, bypassing a bunch of sorting/comparing and duplicate
removal... it simply speeds up the process.
The cache is invalidated wherever a new variable is added to the clobber
lists, but that isn't terribly frequent.
There is no reason we can't use VECs here.
The reason they aren't allocated during operand initialization is to
simply avoid allocating them if it is a function without a relevant
call. I think I would prefer to keep those semantics, but I guess a
couple of small allocations wouldn't be a big deal.
I don't see where you call VEC_alloc in the patch. Does VEC_truncate do
that if it isn't allocated??
> If you are secretly planning another big operand patch, I'll hold, so
> please let me know. :-)
No more big patches :-)