This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] tree-outof-ssa.c: VECify stmt_list.
- 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: Tue, 03 May 2005 13:38:52 -0400
- Subject: Re: [patch] tree-outof-ssa.c: VECify stmt_list.
- References: <20050503.131208.10815492.kazu@cs.umass.edu>
On Tue, 2005-05-03 at 13:12, Kazu Hirata wrote:
> Hi,
>
> Attached is a patch to VECify stmt_list.
>
> Andrew, we have several options here.
>
> o Go with the simple VARRAY -> VEC(tree,gc)* option. (This is what
> the patch below does.)
>
> o Allocate and free these work areas on heap in analyze_edges_for_bb
> since the use of the memory does not "escape" the function.
>
> o Allocate and free these work areas in perform_edge_inserts so that
> you won't have to allocate and free them every time
> analyze_edges_for_bb is called.
>
> I would prefer the second and third option, but I am asking you
> because you seem to want to reuse the memory from previous call to
> analyze_edge_for_bb. Well, reusing the memory may be the only
> reasonable thing you can do with VARRAY on GC. :-)
Presumably you are planning to do the same conversion to the edge_leader
vector.
2) means you will do an allocation and a free everytime we call the
function, which seems wasteful and consumes time. I don't like that.
3) means that perform_edge_inserts has to know something about the
internals of analyze_edge_for_bb, which I don't like from a design
esthetic. Its certainly better than 2), and isn't really a big deal
simply because we are talking about a single routine as opposed to a
real interface of some sort.
I have no strong feelings about 1) or 3), so you can go with 3) if you
want.
Andrew