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.

Thanks for review,
Martin


The rest looks OK and along the plan.

Thanks,
Richard.

jeff


Reply via email to