diff mbox series

Fix a memory leak in vr-values

Message ID 20180925073814.GZ8250@tucnak
State New
Headers show
Series Fix a memory leak in vr-values | expand

Commit Message

Jakub Jelinek Sept. 25, 2018, 7:38 a.m. UTC 
Hi!

I've noticed that in the last few days we leak memory.
The problem is that vr_values ctor allocates 2 vectors, but
~vr_values doesn't free them, only verifies they aren't empty, they are
released by the cleanup_edges_and_switches method.
Some evrp walker users do call that method, but others like the sprintf time
that use evrp only in a read-only way, without ever calling
simplify_stmt_using_ranges, don't.  In that latter case they don't push
anything to the vectors though.
The following patch just makes those vectors empty in the ctor, doesn't
allocate anything, which is better for memory-wise for the sprintf pass as
well as functions that don't contain any switches, or don't have any
switches that can be actually optimized using ranges, those vectors will be
allocated only during safe_push when actually needed.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-09-25  Jakub Jelinek  <jakub@redhat.com>

	* vr-values.c (vr_values::vr_values): Initialize to_remove_edges and
	to_update_switch_stmts to vNULL instead of calling create on them
	immediately.


	Jakub

Comments

Richard Biener Sept. 25, 2018, 12:42 p.m. UTC | #1 
On Tue, Sep 25, 2018 at 9:38 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> Hi!
>
> I've noticed that in the last few days we leak memory.
> The problem is that vr_values ctor allocates 2 vectors, but
> ~vr_values doesn't free them, only verifies they aren't empty, they are
> released by the cleanup_edges_and_switches method.
> Some evrp walker users do call that method, but others like the sprintf time
> that use evrp only in a read-only way, without ever calling
> simplify_stmt_using_ranges, don't.  In that latter case they don't push
> anything to the vectors though.
> The following patch just makes those vectors empty in the ctor, doesn't
> allocate anything, which is better for memory-wise for the sprintf pass as
> well as functions that don't contain any switches, or don't have any
> switches that can be actually optimized using ranges, those vectors will be
> allocated only during safe_push when actually needed.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2018-09-25  Jakub Jelinek  <jakub@redhat.com>
>
>         * vr-values.c (vr_values::vr_values): Initialize to_remove_edges and
>         to_update_switch_stmts to vNULL instead of calling create on them
>         immediately.
>
> --- gcc/vr-values.c.jj  2018-09-24 10:36:54.556016724 +0200
> +++ gcc/vr-values.c     2018-09-24 22:48:59.358094832 +0200
> @@ -1919,8 +1919,8 @@ vr_values::vr_values () : vrp_value_rang
>    vr_value = XCNEWVEC (value_range *, num_vr_values);
>    vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names);
>    bitmap_obstack_initialize (&vrp_equiv_obstack);
> -  to_remove_edges.create (10);
> -  to_update_switch_stmts.create (5);
> +  to_remove_edges = vNULL;
> +  to_update_switch_stmts = vNULL;
>  }
>
>  /* Free VRP lattice.  */
>
>         Jakub
diff mbox series

Patch

--- gcc/vr-values.c.jj	2018-09-24 10:36:54.556016724 +0200
+++ gcc/vr-values.c	2018-09-24 22:48:59.358094832 +0200
@@ -1919,8 +1919,8 @@  vr_values::vr_values () : vrp_value_rang
   vr_value = XCNEWVEC (value_range *, num_vr_values);
   vr_phi_edge_counts = XCNEWVEC (int, num_ssa_names);
   bitmap_obstack_initialize (&vrp_equiv_obstack);
-  to_remove_edges.create (10);
-  to_update_switch_stmts.create (5);
+  to_remove_edges = vNULL;
+  to_update_switch_stmts = vNULL;
 }
 
 /* Free VRP lattice.  */