public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r14-4325] use *_grow_cleared rather than *_grow on vec<bitmap_head>
Date: Fri, 29 Sep 2023 07:42:27 +0000 (GMT)	[thread overview]
Message-ID: <20230929074227.282473858C52@sourceware.org> (raw)

https://gcc.gnu.org/g:a561369743025fd64a3d87bc571d0503b17a82c8

commit r14-4325-ga561369743025fd64a3d87bc571d0503b17a82c8
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Sep 29 09:35:01 2023 +0200

    use *_grow_cleared rather than *_grow on vec<bitmap_head>
    
    The assert checking which is commented out in vec.h grow method requires
    trivially default constructible types to be used with this method, but
    bitmap_head has since the PR88317 r9-4642 workaround non-trivial default
    constructor to catch bugs and we pay the minimum price of initializing
    everything in bitmap_head twice on the common
      bitmap_head var;
      bitmap_initilize (&var, obstack);
    sequence.  This patch makes us pay the same price times number of elements
    on
      vec<bitmap_head> v;
      v.create (n);
      v.safe_grow_cleared (n); // previous v.safe_grow (n);
      for (int i = 0; i < n; ++i)
        bitmap_initialize (&v[i], obstack);
    
    2023-09-29  Jakub Jelinek  <jakub@redhat.com>
    
            * tree-ssa-loop-im.cc (tree_ssa_lim_initialize): Use quick_grow_cleared
            instead of quick_grow on vec<bitmap_head> members.
            * cfganal.cc (control_dependences::control_dependences): Likewise.
            * rtl-ssa/blocks.cc (function_info::build_info::build_info): Likewise.
            (function_info::place_phis): Use safe_grow_cleared instead of safe_grow
            on auto_vec<bitmap_head> vars.
            * tree-ssa-live.cc (compute_live_vars): Use quick_grow_cleared instead
            of quick_grow on vec<bitmap_head> var.

Diff:
---
 gcc/cfganal.cc          | 2 +-
 gcc/rtl-ssa/blocks.cc   | 6 +++---
 gcc/tree-ssa-live.cc    | 2 +-
 gcc/tree-ssa-loop-im.cc | 6 +++---
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/cfganal.cc b/gcc/cfganal.cc
index cc858b99e64..490eef7ebfe 100644
--- a/gcc/cfganal.cc
+++ b/gcc/cfganal.cc
@@ -468,7 +468,7 @@ control_dependences::control_dependences ()
 
   bitmap_obstack_initialize (&m_bitmaps);
   control_dependence_map.create (last_basic_block_for_fn (cfun));
-  control_dependence_map.quick_grow (last_basic_block_for_fn (cfun));
+  control_dependence_map.quick_grow_cleared (last_basic_block_for_fn (cfun));
   for (int i = 0; i < last_basic_block_for_fn (cfun); ++i)
     bitmap_initialize (&control_dependence_map[i], &m_bitmaps);
   for (int i = 0; i < num_edges; ++i)
diff --git a/gcc/rtl-ssa/blocks.cc b/gcc/rtl-ssa/blocks.cc
index 1f9969d78d8..d46cbf1e388 100644
--- a/gcc/rtl-ssa/blocks.cc
+++ b/gcc/rtl-ssa/blocks.cc
@@ -57,7 +57,7 @@ function_info::build_info::build_info (unsigned int num_regs,
   // write to an entry before reading from it.  But poison the contents
   // when checking, just to make sure we don't accidentally use an
   // uninitialized value.
-  bb_phis.quick_grow (num_bb_indices);
+  bb_phis.quick_grow_cleared (num_bb_indices);
   bb_mem_live_out.quick_grow (num_bb_indices);
   bb_to_rpo.quick_grow (num_bb_indices);
   if (flag_checking)
@@ -614,7 +614,7 @@ function_info::place_phis (build_info &bi)
 
   // Calculate dominance frontiers.
   auto_vec<bitmap_head> frontiers;
-  frontiers.safe_grow (num_bb_indices);
+  frontiers.safe_grow_cleared (num_bb_indices);
   for (unsigned int i = 0; i < num_bb_indices; ++i)
     bitmap_initialize (&frontiers[i], &bitmap_default_obstack);
   compute_dominance_frontiers (frontiers.address ());
@@ -626,7 +626,7 @@ function_info::place_phis (build_info &bi)
   // they are live on entry to the corresponding block, but do not need
   // phi nodes otherwise.
   auto_vec<bitmap_head> unfiltered;
-  unfiltered.safe_grow (num_bb_indices);
+  unfiltered.safe_grow_cleared (num_bb_indices);
   for (unsigned int i = 0; i < num_bb_indices; ++i)
     bitmap_initialize (&unfiltered[i], &bitmap_default_obstack);
 
diff --git a/gcc/tree-ssa-live.cc b/gcc/tree-ssa-live.cc
index 8d8a3189ead..f06daf23035 100644
--- a/gcc/tree-ssa-live.cc
+++ b/gcc/tree-ssa-live.cc
@@ -1361,7 +1361,7 @@ compute_live_vars (struct function *fn, live_vars_map *vars)
      We then do a mostly classical bitmap liveness algorithm.  */
 
   active.create (last_basic_block_for_fn (fn));
-  active.quick_grow (last_basic_block_for_fn (fn));
+  active.quick_grow_cleared (last_basic_block_for_fn (fn));
   for (int i = 0; i < last_basic_block_for_fn (fn); i++)
     bitmap_initialize (&active[i], &bitmap_default_obstack);
 
diff --git a/gcc/tree-ssa-loop-im.cc b/gcc/tree-ssa-loop-im.cc
index 6931b61f54e..49aeb685773 100644
--- a/gcc/tree-ssa-loop-im.cc
+++ b/gcc/tree-ssa-loop-im.cc
@@ -3496,13 +3496,13 @@ tree_ssa_lim_initialize (bool store_motion)
     (mem_ref_alloc (NULL, 0, UNANALYZABLE_MEM_ID));
 
   memory_accesses.refs_loaded_in_loop.create (number_of_loops (cfun));
-  memory_accesses.refs_loaded_in_loop.quick_grow (number_of_loops (cfun));
+  memory_accesses.refs_loaded_in_loop.quick_grow_cleared (number_of_loops (cfun));
   memory_accesses.refs_stored_in_loop.create (number_of_loops (cfun));
-  memory_accesses.refs_stored_in_loop.quick_grow (number_of_loops (cfun));
+  memory_accesses.refs_stored_in_loop.quick_grow_cleared (number_of_loops (cfun));
   if (store_motion)
     {
       memory_accesses.all_refs_stored_in_loop.create (number_of_loops (cfun));
-      memory_accesses.all_refs_stored_in_loop.quick_grow
+      memory_accesses.all_refs_stored_in_loop.quick_grow_cleared
 						      (number_of_loops (cfun));
     }

                 reply	other threads:[~2023-09-29  7:42 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230929074227.282473858C52@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).