From patchwork Fri Mar 1 08:34:28 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 208693 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2097:b0:108:e6aa:91d0 with SMTP id gs23csp938698dyb; Fri, 1 Mar 2024 00:35:51 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCVrveMqAIexRlfBuizMUrkGAzI9vfjEu6rBy7ujewvP0NkbFBpE3NPV86UD/TmYrxknDA1KQWzhPrINJusFW6Q7Pyh/7w== X-Google-Smtp-Source: AGHT+IFb3GcVFVd/i54p9ewIJSBz/rjxPEP4ktBc2yFYUaG613fc0mDxhMQpERL2N0hmhYQUndIt X-Received: by 2002:a67:cfc4:0:b0:472:8f78:8e0b with SMTP id h4-20020a67cfc4000000b004728f788e0bmr645758vsm.31.1709282151630; Fri, 01 Mar 2024 00:35:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709282151; cv=pass; d=google.com; s=arc-20160816; b=Ms5bjv60fjgpHUsMKMq47dI7JXEmi+k6wMHD7hTyDQ+L0rLC5xiqE3YoMNiQVj8vsx /IAUDUzgX8kpuTJggZp4X8AfG0u83WouXy41nm+sFaLORMBtqXKOrsvCySWRHBdcw4Vl L/hGwv6UAIcLainspar5E1xAp6tlKO1qPMDFeVe0yMOMgnhhrPOCML8WzYDyn51P4AYv 9IfRhCxupN0zYY3c+oCA4lqig2WnNlFm0H7XEWSpsHbFaFjTrjYeZS8fNO233Ev40mnv 4Iuaswf3efCu/ETXEtEaNKHTCWoDS9IiXeeZ3Eix3j9SEQBR4aHlRgGXy8KNru0bA/uo navg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:reply-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature :arc-filter:dmarc-filter:delivered-to; bh=yVYiEFo4VBL+CGFKcGsPvsWynJKtydJvqxD5wZLoyoM=; fh=AxS+8Hw1cEtrLDwgR3jB25bPK27BPel91LMJCKvtZ9I=; b=WmcYY3Fg4ukW6QWjKwpuTAIph8X9yhXpWvOBE11Cn/J7D6GBWY34A9mUEGhru7d8L4 QGbJWSGnUhPnloE1hZKoe+HcT7nrrzpAQvK6g6zcb8fX1aemoG4BoWlIPTPaLcg23rtL aM2dFitaSVeDI1PuHYfsNiW2MPamb3k2qayjxT7RP2WJg/XHX39LT5WR8b1AV7OJn6y0 RCzFy42ce5WcaGAzzNPLLtK4NGytsZPOgxyVLqwlO3+BnbOCoqgp9NjPSJMR+ryjZpKm DrdaLtnYJRD+r+TSH/B5e4xtBxXrbadMTOz7vgFA+SerzuPytC0D6bphg3vucnoFkk9h RyoA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QUqNfaD0; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id yf12-20020a05620a3bcc00b00785d65274b8si3201501qkn.37.2024.03.01.00.35.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 00:35:51 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QUqNfaD0; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 363F53858C74 for ; Fri, 1 Mar 2024 08:35:50 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 D3F493858D39 for ; Fri, 1 Mar 2024 08:34:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D3F493858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D3F493858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709282076; cv=none; b=M4R2vuPGg6ZysGboHuBWzO44g47o60JXSacSLt0zdObKqyY2wOz2tXA/JCCPySzaXpS3bser9ykTC86hmYfQrXY8RKSj9Zb5H+z/KFmFEjcsx7NZHqUvZyTo9HsUBnTJhtLJlqMEggTuw/x6KhSY0vRabZ9joUV+y4WIhOrx8QI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709282076; c=relaxed/simple; bh=QNQj2fjCsBSJGG5WJ5tcgpG5ThF7EA/FRgFiX2RynFw=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=oFwq3j6ZcaOwrXXJdGbWTPqFxFsmZEpQ3wlQgiFSuhENQaIeJPrXMjD0fCqa/2qo52PuHX1nkn+gPB5F40UEM8IJuc9yWI2uT0BX0b1CtPcOxq4z9GhO4Rbg9cCqKCj36WQEfTT2kb9YiCSNPfd6dCx3fwrMv3oxYXdXJMox5n0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709282073; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type; bh=yVYiEFo4VBL+CGFKcGsPvsWynJKtydJvqxD5wZLoyoM=; b=QUqNfaD0m+OcZlm2zF/YRq/Yea9Sl6IKGHzaokxFCQlXR4l1AvskvbmUdeam5B8r0sanqr klzCkAnGHtAN+/lKAdM7cDdaSTBZq75wWx75ukeR2v+jwDOBBAWVcjuujz5nwk0+akV1ej 0zncSjsL3db5EcQ7xblUdlSIPmqDmI4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-435-eKJdCkkWMFauWf6M_GBU7A-1; Fri, 01 Mar 2024 03:34:30 -0500 X-MC-Unique: eKJdCkkWMFauWf6M_GBU7A-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 91F8686EB28; Fri, 1 Mar 2024 08:34:30 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.226.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 52D8A4D90F; Fri, 1 Mar 2024 08:34:30 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 4218YSfF506304 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 1 Mar 2024 09:34:28 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 4218YSW1506303; Fri, 1 Mar 2024 09:34:28 +0100 Date: Fri, 1 Mar 2024 09:34:28 +0100 From: Jakub Jelinek To: Richard Biener , "Joseph S. Myers" , Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] function: Fix another TYPE_NO_NAMED_ARGS_STDARG_P spot Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SCC_5_SHORT_WORD_LINES, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Jakub Jelinek Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792312241579014482 X-GMAIL-MSGID: 1792312241579014482 Hi! When looking at PR114175 (although that bug seems to be now a riscv backend bug), I've noticed that for the TYPE_NO_NAMED_ARGS_STDARG_P functions which return value through hidden reference, like #include struct S { char a[64]; }; int n; struct S foo (...) { struct S s = {}; va_list ap; va_start (ap); for (int i = 0; i < n; ++i) if ((i & 1)) s.a[0] += va_arg (ap, double); else s.a[0] += va_arg (ap, int); va_end (ap); return s; } we were incorrectly calling assign_parms_setup_varargs twice, once at the start of the function and once in if (cfun->stdarg && !DECL_CHAIN (parm)) assign_parms_setup_varargs (&all, &data, false); where parm is the last and only "named" parameter. The first call, guarded with TYPE_NO_NAMED_ARGS_STDARG_P, was added in r13-3549 and is needed for int bar (...) etc. functions using va_start/va_arg/va_end, otherwise the FOR_EACH_VEC_ELT (fnargs, i, parm) in which the other call is will not iterate at all. But we shouldn't be doing that if we have the hidden return pointer. With the following patch on the above testcase with -O0 -std=c23 the assembly difference is: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 pushq %rbx subq $192, %rsp .cfi_offset 3, -24 - movq %rdi, -192(%rbp) - movq %rsi, -184(%rbp) - movq %rdx, -176(%rbp) - movq %rcx, -168(%rbp) - movq %r8, -160(%rbp) - movq %r9, -152(%rbp) - testb %al, %al - je .L2 - movaps %xmm0, -144(%rbp) - movaps %xmm1, -128(%rbp) - movaps %xmm2, -112(%rbp) - movaps %xmm3, -96(%rbp) - movaps %xmm4, -80(%rbp) - movaps %xmm5, -64(%rbp) - movaps %xmm6, -48(%rbp) - movaps %xmm7, -32(%rbp) -.L2: movq %rdi, -312(%rbp) movq %rdi, -192(%rbp) movq %rsi, -184(%rbp) movq %rdx, -176(%rbp) movq %rcx, -168(%rbp) movq %r8, -160(%rbp) movq %r9, -152(%rbp) testb %al, %al - je .L13 + je .L12 movaps %xmm0, -144(%rbp) movaps %xmm1, -128(%rbp) movaps %xmm2, -112(%rbp) movaps %xmm3, -96(%rbp) movaps %xmm4, -80(%rbp) movaps %xmm5, -64(%rbp) movaps %xmm6, -48(%rbp) movaps %xmm7, -32(%rbp) -.L13: +.L12: plus some renumbering of labels later on which clearly shows that because of this bug, we were saving all the registers twice rather then once. With -O2 -std=c23 some of it is DCEd, but we still get subq $160, %rsp .cfi_def_cfa_offset 168 - testb %al, %al - je .L2 - movaps %xmm0, 24(%rsp) - movaps %xmm1, 40(%rsp) - movaps %xmm2, 56(%rsp) - movaps %xmm3, 72(%rsp) - movaps %xmm4, 88(%rsp) - movaps %xmm5, 104(%rsp) - movaps %xmm6, 120(%rsp) - movaps %xmm7, 136(%rsp) -.L2: movq %rdi, -24(%rsp) movq %rsi, -16(%rsp) movq %rdx, -8(%rsp) movq %rcx, (%rsp) movq %r8, 8(%rsp) movq %r9, 16(%rsp) testb %al, %al - je .L13 + je .L12 movaps %xmm0, 24(%rsp) movaps %xmm1, 40(%rsp) movaps %xmm2, 56(%rsp) movaps %xmm3, 72(%rsp) movaps %xmm4, 88(%rsp) movaps %xmm5, 104(%rsp) movaps %xmm6, 120(%rsp) movaps %xmm7, 136(%rsp) -.L13: +.L12: difference, i.e. this time not all, but the floating point args were conditionally all saved twice. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2024-03-01 Jakub Jelinek * function.cc (assign_parms): Only call assign_parms_setup_varargs early for TYPE_NO_NAMED_ARGS_STDARG_P functions if fnargs is empty. Jakub --- gcc/function.cc.jj 2024-01-12 13:47:20.834428745 +0100 +++ gcc/function.cc 2024-02-29 21:14:35.275889093 +0100 @@ -3650,7 +3650,8 @@ assign_parms (tree fndecl) assign_parms_initialize_all (&all); fnargs = assign_parms_augmented_arg_list (&all); - if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))) + if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl)) + && fnargs.is_empty ()) { struct assign_parm_data_one data = {}; assign_parms_setup_varargs (&all, &data, false);