From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 73F02383D831 for ; Thu, 9 Jun 2022 19:37:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73F02383D831 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-157-tz3oAsbfP2OZyQFQ3h4i1Q-1; Thu, 09 Jun 2022 15:37:20 -0400 X-MC-Unique: tz3oAsbfP2OZyQFQ3h4i1Q-1 Received: by mail-qk1-f198.google.com with SMTP id s8-20020a05620a0bc800b006a6d42a1a0eso7730620qki.3 for ; Thu, 09 Jun 2022 12:37:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=fAa7C/4Kq4N00pZFOlC85AUUFnSk5iR5BvDzj2U2KnI=; b=Dvm7NUhVx0OTQSppABRJ910/jK0knjC8MCAx3ZJ4t1kl0a/uR7PEt7/s31k9KGr9HQ T//5bPRhj6k2EhhN1mIXL4jiJSKrTGVgdon6K9zfHXawSOl0/n+fPbTHQ+kA81qd6LjS 30tC0AIjfgijY01hhZL+Bk6dMWNhiWnb+C2951sMTA8g5wDxBW0rbPRqUv0AcVrhLeVz Hej/Z0TKnDhpDv7JXg5HBTYC4+MYHsV82Y21nTTYIb8AV2MhJLQZBsKVFAC2/z/ggUjT cI/9gfbsDGSUrllTv4hi/MflyhJmHGxe8dzIvXh+q4wfRoEyibEf5Pd0eyt1ncasrDjo NO9g== X-Gm-Message-State: AOAM533tOI8nPO3dib32AKnMOzyWBzFR+GqDrB9PtY9k1TER4JLNgDVF 1b3WMyH1GT3YRzGLYF0BvI9ouoeD9k5ByTs3Eyo0DWWZB3/imRKX4Nmcc39Gm3TYj8c1Oi1rLmr lpFIA94LOer73y28unA== X-Received: by 2002:a37:e304:0:b0:6a6:a784:6276 with SMTP id y4-20020a37e304000000b006a6a7846276mr22540866qki.778.1654803440301; Thu, 09 Jun 2022 12:37:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzymz2uOImHwloKglzexcXH6YwWKiYr6LXCnRgLGhiRuoCtilvNdXvPdEqTp9lfhVgBlBkb7Q== X-Received: by 2002:a37:e304:0:b0:6a6:a784:6276 with SMTP id y4-20020a37e304000000b006a6a7846276mr22540859qki.778.1654803440063; Thu, 09 Jun 2022 12:37:20 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id bl33-20020a05620a1aa100b006a6f1c30701sm6734750qkb.115.2022.06.09.12.37.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jun 2022 12:37:19 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Thu, 9 Jun 2022 15:37:19 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 2/1] c++: optimize specialization of templated member functions In-Reply-To: <012da98c-ff3b-69d8-2d17-346ad2818049@redhat.com> Message-ID: <289337c5-6b62-47c7-10fe-79859ab76f52@idea> References: <20220608182147.4123587-1-ppalka@redhat.com> <20220609130013.250243-1-ppalka@redhat.com> <012da98c-ff3b-69d8-2d17-346ad2818049@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-14.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2022 19:37:25 -0000 On Thu, 9 Jun 2022, Jason Merrill wrote: > On 6/9/22 09:00, Patrick Palka wrote: > > This performs one of the optimizations added by the previous > > patch to lookup_template_class, to instantiate_template as well. > > (For the libstdc++ ranges tests this optimization appears to be > > effective around 30% of the time, i.e. 30% of the time context of 'tmpl' > > is non-dependent while the context of 'gen_tmpl' is dependent.) > > If this is a significant optimization, how about doing it in tsubst_aggr_type > rather than its callers? I'm not sure how we'd do this optimization in tsubst_aggr_type? I haven't observed any significant time/memory improvements based on my limited benchmarking, but I can imagine for deeply nested templates it could be significant. And avoiding redundant work should hopefully help streamline debugging I suppose. > > > gcc/cp/ChangeLog: > > > > * pt.cc (instantiate_template): Don't substitute the context > > of the most general template if that of the partially > > instantiated template is non-dependent. > > --- > > gcc/cp/pt.cc | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > > index e021c254872..208daad298a 100644 > > --- a/gcc/cp/pt.cc > > +++ b/gcc/cp/pt.cc > > @@ -21661,8 +21661,14 @@ instantiate_template (tree tmpl, tree orig_args, > > tsubst_flags_t complain) > > ++processing_template_decl; > > if (DECL_CLASS_SCOPE_P (gen_tmpl)) > > { > > - tree ctx = tsubst_aggr_type (DECL_CONTEXT (gen_tmpl), targ_ptr, > > - complain, gen_tmpl, true); > > + tree ctx; > > + if (!uses_template_parms (DECL_CONTEXT (tmpl))) > > + /* If the context of the partially instantiated template is already > > + non-dependent, then we might as well use it. */ > > + ctx = DECL_CONTEXT (tmpl); > > + else > > + ctx = tsubst_aggr_type (DECL_CONTEXT (gen_tmpl), targ_ptr, > > + complain, gen_tmpl, true); > > push_nested_class (ctx); > > } > > > >