Kill pointers keeping gimple function body around after RTL is generated
Richard Henderson
rth@redhat.com
Fri Sep 3 07:05:00 GMT 2004
On Thu, Sep 02, 2004 at 11:59:06PM +0200, Jan Hubicka wrote:
> - for (; !bsi_end_p (bsi); bsi_next (&bsi))
> + for (; !bsi_end_p (bsi); bsi_remove (&bsi))
Why? Aren't we coing to zap the entire statement list in a moment?
> - if (TREE_CODE (t) == LABEL_EXPR)
> + if (TREE_CODE (t) == LABEL_EXPR && label_to_block_map)
Which probably obviates this change, does it not?
> void
> fini_ssa_operands (void)
> {
> + ggc_free (build_defs);
> + ggc_free (build_uses);
> + ggc_free (build_v_may_defs);
> + ggc_free (build_vuses);
> + ggc_free (build_v_must_defs);
> + build_defs = NULL;
> + build_uses = NULL;
> + build_v_may_defs = NULL;
> + build_vuses = NULL;
> + build_v_must_defs = NULL;
> }
>
>
> Index: tree-ssanames.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/tree-ssanames.c,v
> retrieving revision 2.8
> diff -c -3 -p -r2.8 tree-ssanames.c
> *** tree-ssanames.c 25 Aug 2004 21:21:19 -0000 2.8
> --- tree-ssanames.c 2 Sep 2004 21:54:51 -0000
> *************** init_ssanames (void)
> *** 155,160 ****
> --- 155,162 ----
> void
> fini_ssanames (void)
> {
> + ggc_free (ssa_names);
> + ssa_names = NULL;
> free_ssanames = NULL;
> }
And these are completely unrelated changes?
r~
More information about the Gcc-patches
mailing list