On Tue, Sep 25, 2018 at 9:38 AM Jakub Jelinek <ja...@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 <ja...@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
