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] tree-outof-ssa.c: VECify stmt_list.

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

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


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