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 005203858D35 for ; Wed, 28 Jun 2023 20:15:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 005203858D35 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=1687983312; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aC46k0aFomX2TrrRwniFADoJ76uODR4CYXpWntkPoHM=; b=JuWAt9ZEDSJg9wlqvg8iTFWu26GSCJB+cmnWFbc50OEuYGiLKZZECkMjQkxEg2mpAkjGNx z7IHBg/b+3GTR1uaTrayXyaWFzZ0O2p3aTLsHzvdSFw1YOTtZhv6JJsQpy47Asg8QDcFB1 ydCUYFGK6ImfkfLLn0bwZJNyJ+h9Ucc= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-647-65x2OsYHPKqPKymZVZ1lkA-1; Wed, 28 Jun 2023 16:15:11 -0400 X-MC-Unique: 65x2OsYHPKqPKymZVZ1lkA-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2b69b3ca25fso1751131fa.1 for ; Wed, 28 Jun 2023 13:15:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687983310; x=1690575310; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aC46k0aFomX2TrrRwniFADoJ76uODR4CYXpWntkPoHM=; b=WKsG4BftBDBcjn4XeOZMEghAGqwtVraj/zSb4hORE9U4hbdPXMmU0l8cYDEPKRE+n7 BTJRY6MM9zYERWDM13fnpEbtIJwGo/Aan6uswpLgyO96LOGwsmk+afGDp8BPYRqj8bcn Sicyvy5HACzRQv3WeT3JpXsgNNyFrCuG12y2h8c0SE4K+48eXqxrTuveENYLjUhkxC0z 8yGqKCEHGqtlJdw4JwkcwdEocIVVeDJUeAz/xJtOV5pSMKLBDYieh14tX382OpOTspVa IAHvpm3AH1ETyXNltcyurL1tgr+kkVhYLgKpG3H9LbdbSGp/yxczPVyFXIVOqikrxlXf 0MgA== X-Gm-Message-State: AC+VfDx/ZZLw3Qn+xKHLd5Be6JP18mNqCx6WpNvO+lv1Yl7avTHymYeq QrWgq4raEoNBU69rs4/TA8p5mnqa6G/mobkCCnWAh/wvDIuoQIAkGslgnkKBi7acOEv6dnlC6ML Gr8ce6llFVdZvHNZ5UWHA/PZhe1UQXePtQA== X-Received: by 2002:a2e:b163:0:b0:2b6:a08d:e142 with SMTP id a3-20020a2eb163000000b002b6a08de142mr6924755ljm.7.1687983310085; Wed, 28 Jun 2023 13:15:10 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5SHx5awgcDM3K76DB9EzudqGaQadE0Ej9oF86lmELVViyMlTFo3EDXh2iIqng7WS5Jl8NZVKAiLX9o0MxI+Xw= X-Received: by 2002:a2e:b163:0:b0:2b6:a08d:e142 with SMTP id a3-20020a2eb163000000b002b6a08de142mr6924748ljm.7.1687983309730; Wed, 28 Jun 2023 13:15:09 -0700 (PDT) MIME-Version: 1.0 References: <20230621171920.1283054-1-ppalka@redhat.com> <94b29e42-dfa9-5c05-4f1d-3c5beb998fdf@redhat.com> <26258d18-5718-9387-087b-be58a25048c2@redhat.com> In-Reply-To: <26258d18-5718-9387-087b-be58a25048c2@redhat.com> From: Patrick Palka Date: Wed, 28 Jun 2023 16:14:58 -0400 Message-ID: Subject: Re: [PATCH] c++: redundant targ coercion for var/alias tmpls To: Jason Merrill Cc: gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,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, Jun 28, 2023 at 11:50=E2=80=AFAM Jason Merrill w= rote: > > On 6/23/23 12:23, Patrick Palka wrote: > > On Fri, 23 Jun 2023, Jason Merrill wrote: > > > >> On 6/21/23 13:19, Patrick Palka wrote: > >>> When stepping through the variable/alias template specialization code > >>> paths, I noticed we perform template argument coercion twice: first f= rom > >>> instantiate_alias_template / finish_template_variable and again from > >>> tsubst_decl (during instantiate_template). It should suffice to perf= orm > >>> coercion once. > >>> > >>> To that end patch elides this second coercion from tsubst_decl when > >>> possible. We can't get rid of it completely because we don't always > >>> specialize a variable template from finish_template_variable: we coul= d > >>> also be doing so directly from instantiate_template during variable > >>> template partial specialization selection, in which case the coercion > >>> from tsubst_decl would be the first and only coercion. > >> > >> Perhaps we should be coercing in lookup_template_variable rather than > >> finish_template_variable? > > > > Ah yes, there's a patch for that at > > https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617377.html :) > > So after that patch, can we get rid of the second coercion completely? On second thought it should be possible to get rid of it, if we rearrange things to always pass the primary arguments to tsubst_decl, and perform partial specialization selection from there instead of instantiate_template. Let me try... > > Jason >