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.133.124]) by sourceware.org (Postfix) with ESMTPS id 017E53858407 for ; Wed, 7 Sep 2022 20:40:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 017E53858407 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662583232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=oHDfi/MPDIDjmxKg/F5EAkVPiORzERipaaODXx1Mfjk=; b=LB8sXPskQCqp8UcPvYvIf16taCI5TF8x9Q2oBmphLNi8goL4LNXd68mXWA1jh5iZwrU97w +tUclfcuylQJP+1jDuNZ9ccUmg48Ha18dYFLjOWWlQaTRLJ+A8XHrOwA28dLM+N7pWj0to vGZCfTPif2gaObApp0scSJZOz6bLgWU= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-316-lbrDklm0M9Cv4sGzqnGUCA-1; Wed, 07 Sep 2022 16:40:31 -0400 X-MC-Unique: lbrDklm0M9Cv4sGzqnGUCA-1 Received: by mail-qt1-f198.google.com with SMTP id ci6-20020a05622a260600b0034370b6f5d6so12843519qtb.14 for ; Wed, 07 Sep 2022 13:40:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date; bh=oHDfi/MPDIDjmxKg/F5EAkVPiORzERipaaODXx1Mfjk=; b=H0vmY/YDCjp8gksbV1HD/tCkDdVln0GEC8VlbN9ZGwqgT4K4iAOqfkvyrV2uTvKDQY yK+WKl+XX5lIu8uxXhiNKsfpwkhrWI47wvHaOFm9u60TMst+ZLDAnGRymxwmNGyDLQ9J N3q90xSoA94S4yQocjqLyTkpQ2sNiN1h3CE+EwlrBjzdknYiOOofLp2vTbMny4H+ibjr uvSu2Hd00adHnhaFLX/w1ZnevNlCjU3W6hmZn2E249WEkMY4RTHKUIrxqhRXswgIGsoE ysqBLG0z058O2CNWDMlDU5GgqHKHWsSR0YxH85NEgq9/aNEseEIyCu8n0uSIU67CleEz QZ5Q== X-Gm-Message-State: ACgBeo1aMh3kwT56+ILRIwRb0uli2QZbIJowbgXDEJOu9j6AsZJftM5S 0i8fXudE91NwpUWOgfYPK8NwiSw4ovT7aHF5OKdNNXpTe7REApw3wz5ukJMTI182IWPPKuCOGBU ZlZCFU1TopcJUMgPbzQ== X-Received: by 2002:a05:622a:164f:b0:344:b216:ada6 with SMTP id y15-20020a05622a164f00b00344b216ada6mr5126391qtj.302.1662583231037; Wed, 07 Sep 2022 13:40:31 -0700 (PDT) X-Google-Smtp-Source: AA6agR5kIo4ouNAXXocVWzOV23wL3pfgx9fTnMvT2SZ3quOuY8rVwgKDmczZapb3smJDTeKlY9k7hA== X-Received: by 2002:a05:622a:164f:b0:344:b216:ada6 with SMTP id y15-20020a05622a164f00b00344b216ada6mr5126373qtj.302.1662583230752; Wed, 07 Sep 2022 13:40:30 -0700 (PDT) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id cc20-20020a05622a411400b0035a62b46b25sm160160qtb.30.2022.09.07.13.40.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Sep 2022 13:40:30 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Wed, 7 Sep 2022 16:40:29 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: unnecessary instantiation of constexpr var [PR99130] In-Reply-To: <38d432fb-f9db-6f0f-1587-1b8c0f5c75e7@redhat.com> Message-ID: References: <20220907194100.879066-1-ppalka@redhat.com> <38d432fb-f9db-6f0f-1587-1b8c0f5c75e7@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.5 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_LOW,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 List-Id: On Wed, 7 Sep 2022, Jason Merrill wrote: > On 9/7/22 15:41, Patrick Palka wrote: > > Here the use of the constexpr member/variable specialization 'value' > > from within an unevaluated context causes us to overeagerly instantiate > > it, via maybe_instantiate_decl called from mark_used, despite only its > > declaration not its definition being needed. > > If the issue is with unevaluated context, maybe maybe_instantiate_decl should > guard the call to decl_maybe_constant_var_p with !cp_unevaluated_operand? Hmm, that seems to work too. But IIUC this would mean in an evaluated (but non-constexpr) context we'd continue to instantiate constexpr variables _immediately_ rather than ideally allowing mark_used to postpone their instantiation until the end of TU processing (which is what happens with the below approach). Another benefit of the below approach is that from within a template definition we we now avoid instantiation altogether e.g. for template constexpr int value = /* blah */; template int f() { return value; } we no longer instantiate value which IIUC is consistent with how we handle other kinds of specializations used within a template definition. So making mark_used no longer instantiate constexpr variables immediately (in both evaluated and unevaluated contexts) seems to yield the most benefits. > > > We used to have the same issue for constexpr function specializations > > until r6-1309-g81371eff9bc7ef made us delay their instantiation until > > necessary during constexpr evaluation. > > > > So this patch makes us avoid unnecessarily instantiating constexpr > > variable template specializations from mark_used as well. To that end > > this patch pulls out the test in maybe_instantiate_decl > > > > (decl_maybe_constant_var_p (decl) > > || (TREE_CODE (decl) == FUNCTION_DECL > > && DECL_OMP_DECLARE_REDUCTION_P (decl)) > > || undeduced_auto_decl (decl)) > > > > into each of its three callers (including mark_used) and refines the > > test appropriately. The net result is that only mark_used is changed, > > because the other two callers, resolve_address_of_overloaded_function > > and decl_constant_var_p, already guard the call appropriately. And > > presumably decl_constant_var_p will take care of instantiation when > > needed for e.g. constexpr evaluation. > > > > Bootstrapped and regteste on x86_64-pc-linux-gnu, does this look OK for > > trunk? > > > > PR c++/99130 > > > > gcc/cp/ChangeLog: > > > > * decl2.cc (maybe_instantiate_decl): Adjust function comment. > > Check VAR_OR_FUNCTION_DECL_P. Pull out the disjunction into ... > > (mark_used): ... here, removing the decl_maybe_constant_var_p > > part of it. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/cpp1y/var-templ70.C: New test. > > --- > > gcc/cp/decl2.cc | 33 ++++++++---------------- > > gcc/testsuite/g++.dg/cpp1y/var-templ70.C | 19 ++++++++++++++ > > 2 files changed, 30 insertions(+), 22 deletions(-) > > create mode 100644 gcc/testsuite/g++.dg/cpp1y/var-templ70.C > > > > diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc > > index 89ab2545d64..cd188813bee 100644 > > --- a/gcc/cp/decl2.cc > > +++ b/gcc/cp/decl2.cc > > @@ -5381,24 +5381,15 @@ possibly_inlined_p (tree decl) > > return true; > > } > > -/* Normally, we can wait until instantiation-time to synthesize DECL. > > - However, if DECL is a static data member initialized with a constant > > - or a constexpr function, we need it right now because a reference to > > - such a data member or a call to such function is not value-dependent. > > - For a function that uses auto in the return type, we need to instantiate > > - it to find out its type. For OpenMP user defined reductions, we need > > - them instantiated for reduction clauses which inline them by hand > > - directly. */ > > +/* If DECL is a function or variable template specialization, instantiate > > + its definition now. */ > > void > > maybe_instantiate_decl (tree decl) > > { > > - if (DECL_LANG_SPECIFIC (decl) > > + if (VAR_OR_FUNCTION_DECL_P (decl) > > + && DECL_LANG_SPECIFIC (decl) > > && DECL_TEMPLATE_INFO (decl) > > - && (decl_maybe_constant_var_p (decl) > > - || (TREE_CODE (decl) == FUNCTION_DECL > > - && DECL_OMP_DECLARE_REDUCTION_P (decl)) > > - || undeduced_auto_decl (decl)) > > && !DECL_DECLARED_CONCEPT_P (decl) > > && !uses_template_parms (DECL_TI_ARGS (decl))) > > { > > @@ -5700,15 +5691,13 @@ mark_used (tree decl, tsubst_flags_t complain) > > return false; > > } > > - /* Normally, we can wait until instantiation-time to synthesize DECL. > > - However, if DECL is a static data member initialized with a constant > > - or a constexpr function, we need it right now because a reference to > > - such a data member or a call to such function is not value-dependent. > > - For a function that uses auto in the return type, we need to > > instantiate > > - it to find out its type. For OpenMP user defined reductions, we need > > - them instantiated for reduction clauses which inline them by hand > > - directly. */ > > - maybe_instantiate_decl (decl); > > + /* If DECL has a deduced return type, we need to instantiate it now to > > + find out its type. For OpenMP user defined reductions, we need them > > + instantiated for reduction clauses which inline them by hand directly. > > */ > > + if (undeduced_auto_decl (decl) > > + || (TREE_CODE (decl) == FUNCTION_DECL > > + && DECL_OMP_DECLARE_REDUCTION_P (decl))) > > + maybe_instantiate_decl (decl); > > if (processing_template_decl || in_template_function ()) > > return true; > > diff --git a/gcc/testsuite/g++.dg/cpp1y/var-templ70.C > > b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C > > new file mode 100644 > > index 00000000000..80965657c32 > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/cpp1y/var-templ70.C > > @@ -0,0 +1,19 @@ > > +// PR c++/99130 > > +// { dg-do compile { target c++14 } } > > + > > +template > > +struct A { > > + static constexpr int value = T::value; > > +}; > > + > > +struct B { > > + template > > + static constexpr int value = T::value; > > +}; > > + > > +template > > +constexpr int value = T::value; > > + > > +using ty1 = decltype(A::value); > > +using ty2 = decltype(B::value); > > +using ty3 = decltype(value); > >