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: linkBe 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).