On Tue, Sep 1, 2020 at 1:26 PM Martin Liška <mli...@suse.cz> wrote: > > On 8/27/20 10:54 AM, Richard Biener wrote: > > On Wed, Aug 26, 2020 at 11:02 PM Jeff Law <l...@redhat.com> wrote: > >> > >> On Tue, 2020-08-11 at 13:37 +0200, Martin Liška wrote: > >>> From cc1d41a469d76f2f8e4f44bed788ace77a1c6d62 Mon Sep 17 00:00:00 2001 > >>> From: Martin Liska <mli...@suse.cz> > >>> Date: Mon, 10 Aug 2020 12:09:19 +0200 > >>> Subject: [PATCH 3/3] vec: use inexact growth where possible. > >>> > >>> gcc/ChangeLog: > >>> > >>> * cfgrtl.c (rtl_create_basic_block): Use default value for > >>> growth vector function. > >>> * gimple.c (gimple_set_bb): Likewise. > >>> * symbol-summary.h: Likewise. > >>> * tree-cfg.c (init_empty_tree_cfg_for_function): Likewise. > >>> (build_gimple_cfg): Likewise. > >>> (create_bb): Likewise. > >>> (move_block_to_fn): Likewise. > >> I'll note that in some cases we were avoiding exponential growth in our > >> new size > >> computations. Presumably the inexact growth support will do something > >> similar, > >> even if it's not exactly the same. Right? Assuming that's the case this > >> is OK > >> too. > > > > @@ -183,12 +183,12 @@ init_empty_tree_cfg_for_function (struct function *fn) > > last_basic_block_for_fn (fn) = NUM_FIXED_BLOCKS; > > vec_alloc (basic_block_info_for_fn (fn), initial_cfg_capacity); > > vec_safe_grow_cleared (basic_block_info_for_fn (fn), > > - initial_cfg_capacity, true); > > + initial_cfg_capacity); > > > > /* Build a mapping of labels to their associated blocks. */ > > vec_alloc (label_to_block_map_for_fn (fn), initial_cfg_capacity); > > vec_safe_grow_cleared (label_to_block_map_for_fn (fn), > > - initial_cfg_capacity, true); > > + initial_cfg_capacity); > > > > this is odd now at least since we explicitely alloc initial_cfg_capacity. > > IMHO we should instead use > > > > basic_block_info_for_fn (fn)->quick_grow_cleared (initial_cfg_capacity) > > > > here? > > Yes, with the following small change: > > + vec_safe_grow_cleared (basic_block_info_for_fn (fn), > + initial_cfg_capacity, true); > > as basic_block_info_for_fn (fn) is NULL.
But we alloc it previously to exact size? OK, you can drop the vec_alloc calls of course. > Thanks for review, > Martin > > > > > The rest looks OK and along the plan. > > > > Thanks, > > Richard. > > > >> jeff > >> >
