public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Patrick Palka <ppalka@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++: cache partial template specialization selection
Date: Wed, 28 Jun 2023 16:30:52 -0400	[thread overview]
Message-ID: <f6b173e7-359f-ddd7-7cec-1a31ef367731@redhat.com> (raw)
In-Reply-To: <20230628165129.2429217-1-ppalka@redhat.com>

On 6/28/23 12:51, Patrick Palka wrote:
> There's currently no cheap way to obtain the partial template
> specialization (and arguments relative to it) that was selected for a
> class or variable template specialization.  Our only option is to
> compute the result from scratch via most_specialized_partial_spec.
> 
> For class templates this isn't really an issue because we usually need
> this information just once, upon instantiation.  But for variable
> templates we need it upon specialization and later upon instantiation.
> It'd be good for this information to be readily available in general
> however.
> 
> To that end, this patch adds a TI_PARTIAL_INFO field to TEMPLATE_INFO
> that holds another TEMPLATE_INFO consisting of the partial template and
> arguments relative to it, which most_specialized_partial_spec then
> uses to transparently cache its (now TEMPLATE_INFO) result.
> > Similarly, there's no easy way to go from the DECL_TEMPLATE_RESULT of a
> partial TEMPLATE_DECL back to the TEMPLATE_DECL.  (Our best option is to
> walk the DECL_TEMPLATE_SPECIALIZATIONS list of the primary TEMPLATE_DECL.)
> So this patch also uses this new field to link these entities in this
> other direction.

You had talked about this possibly replacing the deferred_access_checks; 
could they share the same slot by anonymous union?  Your second use 
would conflict, but perhaps the checks could move to the TEMPLATE_INFO 
of the TEMPLATE_DECL now that we have a way to get at it?

In any case, this patch is OK.

Jason


      reply	other threads:[~2023-06-28 20:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 16:51 Patrick Palka
2023-06-28 20:30 ` Jason Merrill [this message]

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=f6b173e7-359f-ddd7-7cec-1a31ef367731@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ppalka@redhat.com \
    /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).