public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Richard Sandiford <rsandifo@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r14-2180] A couple of va_gc_atomic tweaks
Date: Thu, 29 Jun 2023 07:48:27 +0000 (GMT)	[thread overview]
Message-ID: <20230629074827.4C4F63858D35@sourceware.org> (raw)

https://gcc.gnu.org/g:4e9f6c14280699997a633cefd3fb315b2bd4762c

commit r14-2180-g4e9f6c14280699997a633cefd3fb315b2bd4762c
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Thu Jun 29 08:48:17 2023 +0100

    A couple of va_gc_atomic tweaks
    
    The only current user of va_gc_atomic is Ada's:
    
        vec<Entity_Id, va_gc_atomic>
    
    It uses the generic gt_pch_nx routines (with gt_pch_nx being the
    “note pointers” hooks), such as:
    
        template<typename T, typename A>
        void
        gt_pch_nx (vec<T, A, vl_embed> *v)
        {
          extern void gt_pch_nx (T &);
          for (unsigned i = 0; i < v->length (); i++)
            gt_pch_nx ((*v)[i]);
        }
    
    It then defines gt_pch_nx routines for Entity_Id &.
    
    The problem is that if we wanted to take the same approach for
    an array of unsigned ints, we'd need to define:
    
        inline void gt_pch_nx (unsigned int &) { }
    
    which would then be ambiguous with:
    
        inline void gt_pch_nx (unsigned int) { }
    
    The point of va_gc_atomic is that the elements don't need to be GCed,
    and so we have:
    
        template<typename T>
        void
        gt_ggc_mx (vec<T, va_gc_atomic, vl_embed> *v ATTRIBUTE_UNUSED)
        {
          /* Nothing to do.  Vectors of atomic types wrt GC do not need to
             be traversed.  */
        }
    
    I think it's therefore reasonable to assume that no pointers will
    need to be processed for PCH either.
    
    The patch also relaxes the array_slice constructor for vec<T, va_gc> *
    so that it handles all embedded vectors.
    
    gcc/
            * vec.h (gt_pch_nx): Add overloads for va_gc_atomic.
            (array_slice): Relax va_gc constructor to handle all vectors
            with a vl_embed layout.
    
    gcc/ada/
            * gcc-interface/decl.cc (gt_pch_nx): Remove overloads for Entity_Id.

Diff:
---
 gcc/ada/gcc-interface/decl.cc | 11 -----------
 gcc/vec.h                     | 22 ++++++++++++++++++----
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/gcc/ada/gcc-interface/decl.cc b/gcc/ada/gcc-interface/decl.cc
index 494b24e2111..ee913a017d2 100644
--- a/gcc/ada/gcc-interface/decl.cc
+++ b/gcc/ada/gcc-interface/decl.cc
@@ -163,17 +163,6 @@ struct GTY((for_user)) tree_entity_vec_map
   vec<Entity_Id, va_gc_atomic> *to;
 };
 
-void
-gt_pch_nx (Entity_Id &)
-{
-}
-
-void
-gt_pch_nx (Entity_Id *x, gt_pointer_operator op, void *cookie)
-{
-  op (x, NULL, cookie);
-}
-
 struct dummy_type_hasher : ggc_cache_ptr_hash<tree_entity_vec_map>
 {
   static inline hashval_t
diff --git a/gcc/vec.h b/gcc/vec.h
index 36918915701..6f7b0487eb6 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1390,6 +1390,13 @@ gt_pch_nx (vec<T, A, vl_embed> *v)
     gt_pch_nx ((*v)[i]);
 }
 
+template<typename T>
+void
+gt_pch_nx (vec<T, va_gc_atomic, vl_embed> *)
+{
+  /* No pointers to note.  */
+}
+
 template<typename T, typename A>
 void
 gt_pch_nx (vec<T *, A, vl_embed> *v, gt_pointer_operator op, void *cookie)
@@ -1407,6 +1414,13 @@ gt_pch_nx (vec<T, A, vl_embed> *v, gt_pointer_operator op, void *cookie)
     gt_pch_nx (&((*v)[i]), op, cookie);
 }
 
+template<typename T>
+void
+gt_pch_nx (vec<T, va_gc_atomic, vl_embed> *, gt_pointer_operator, void *)
+{
+  /* No pointers to note.  */
+}
+
 
 /* Space efficient vector.  These vectors can grow dynamically and are
    allocated together with their control data.  They are suited to be
@@ -2286,12 +2300,12 @@ public:
   array_slice (vec<OtherT> &v)
     : m_base (v.address ()), m_size (v.length ()) {}
 
-  template<typename OtherT>
-  array_slice (const vec<OtherT, va_gc> *v)
+  template<typename OtherT, typename A>
+  array_slice (const vec<OtherT, A, vl_embed> *v)
     : m_base (v ? v->address () : nullptr), m_size (v ? v->length () : 0) {}
 
-  template<typename OtherT>
-  array_slice (vec<OtherT, va_gc> *v)
+  template<typename OtherT, typename A>
+  array_slice (vec<OtherT, A, vl_embed> *v)
     : m_base (v ? v->address () : nullptr), m_size (v ? v->length () : 0) {}
 
   iterator begin () { return m_base; }

                 reply	other threads:[~2023-06-29  7:48 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=20230629074827.4C4F63858D35@sourceware.org \
    --to=rsandifo@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).