From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 42DFE3858D35; Sun, 30 Apr 2023 19:00:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42DFE3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-63b7588005fso1430516b3a.0; Sun, 30 Apr 2023 12:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682881254; x=1685473254; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=f2/xa3OINwtr3q9HH6F0l6iCx/u60DGCATholn0ypiQ=; b=A3jq7qyAKrWSBaCiGmUBVAWWB18UORymhOS6v7LyJTbhCKq9vr/fDOOIMBLIIclNuq qs8aD42WGiLy0+AAEhWFrd5zA+xG2IYlzZpP3k4A4K9VOPWAlEyDGUn2JIOSk/c8qTG/ Zqf1dbzavxf1XNqvMHTwBvh1+LBnXklYxnKDnyggVfxCbJIrUS8rYHH3LZlSRWc3icWl soKgOYJm+7Dy6NreBESdCLbh/HQR5MDvyOpyNzhfnqXsuMPUt4nzs6lQlgNYmOzp0BFG FQw1ygW1qmmqPXrrU6TybDQF7CULH6/PsS00izn1DcQJgl8Qe+j2HUhtvOD5VPkGhOm4 2y+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682881254; x=1685473254; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=f2/xa3OINwtr3q9HH6F0l6iCx/u60DGCATholn0ypiQ=; b=PaYgEMPuhAORyauIjrshNfm99xAqjwUkr3D8qurlq/JLOHnJ3oZ/m3hVD9nWSGNlp0 1boMRxaB20pP6rUEZ2aQH1WEU2PGLwaws1IP1jk9ZHuzuSdtbBQ/Zyph/q+iQBx+kBUk t4Dz9Vq84qUwA48V4soSZgs9ntp/mlpb1KVwv5CmW4N4hi1+W0lSTr4fNtyOj+bRriMT kS7Cj55IOR5GRH3eC1bULs5ngSXY8ZLDsTzZ9AQk+iPgjnr4H4RNf34CvSh+emwdN0aq oXGh7dwDIhJm/ZP6BdA4F2DDucwU6r01MC/xTwFCrVXOhLvWQ6+gmMVPb9uUJfV2ZDe7 RlNA== X-Gm-Message-State: AC+VfDwyfa2K2A6Phwz/ZFQrnhZsDqkoT/TD0uPtpsmOS8mNnA9vCsUX i+EZgyhji63Yd4jhZbPXGo0= X-Google-Smtp-Source: ACHHUZ6++1XI3yVas8wvOpR9nbjUaGdjSy6FIXNX7eKUgNvnZ6P38gOsX+sQqSMvyvsKJ7jWbR4/aQ== X-Received: by 2002:aa7:8890:0:b0:63b:85a0:142a with SMTP id z16-20020aa78890000000b0063b85a0142amr17859040pfe.3.1682881254010; Sun, 30 Apr 2023 12:00:54 -0700 (PDT) Received: from ?IPV6:2601:681:8600:13d0::99f? ([2601:681:8600:13d0::99f]) by smtp.gmail.com with ESMTPSA id n11-20020a056a00212b00b0063f167b41bdsm17052610pfj.38.2023.04.30.12.00.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Apr 2023 12:00:53 -0700 (PDT) Message-ID: <0221bead-5d08-cb56-e620-642825c1abc3@gmail.com> Date: Sun, 30 Apr 2023 13:00:51 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Subject: Re: [PATCH V5] Use reg mode to move sub blocks for parameters and returns Content-Language: en-US To: Jiufu Guo , gcc-patches@gcc.gnu.org Cc: rguenther@suse.de, segher@kernel.crashing.org, dje.gcc@gmail.com, linkw@gcc.gnu.org, meissner@linux.ibm.com References: <20230317033952.1549050-1-guojiufu@linux.ibm.com> From: Jeff Law In-Reply-To: <20230317033952.1549050-1-guojiufu@linux.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 3/16/23 21:39, Jiufu Guo wrote: > Hi, > > When assigning a parameter to a variable, or assigning a variable to > return value with struct type, and the parameter/return is passed > through registers. > For this kind of case, it would be better to use the nature mode of > the registers to move the content for the assignment. > > As the example code (like code in PR65421): > > typedef struct SA {double a[3];} A; > A ret_arg_pt (A *a) {return *a;} // on ppc64le, expect only 3 lfd(s) > A ret_arg (A a) {return a;} // just empty fun body > void st_arg (A a, A *p) {*p = a;} //only 3 stfd(s) > > Comparing with previous version: > https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609394.html > This version refine code to eliminated reductant code in the sub > routine "move_sub_blocks". > > Bootstrap and regtest pass on ppc64{,le}. > Is this ok for trunk? > > BR, > Jeff (Jiufu) > > PR target/65421 > > gcc/ChangeLog: > > * cfgexpand.cc (expand_used_vars): Update to mark DECL_USEDBY_RETURN_P > for returns. > * expr.cc (move_sub_blocks): New function. > (expand_assignment): Update assignment code about returns/parameters. > * function.cc (assign_parm_setup_block): Update to mark > DECL_REGS_TO_STACK_P for parameter. > * tree-core.h (struct tree_decl_common): Add comment. > * tree.h (DECL_USEDBY_RETURN_P): New define. > (DECL_REGS_TO_STACK_P): New define. > > gcc/testsuite/ChangeLog: > > * gcc.target/powerpc/pr65421-1.c: New test. > * gcc.target/powerpc/pr65421.c: New test. > > --- > gcc/cfgexpand.cc | 14 +++++ > gcc/expr.cc | 61 ++++++++++++++++++++ > gcc/function.cc | 3 + > gcc/tree-core.h | 4 +- > gcc/tree.h | 9 +++ > gcc/testsuite/gcc.target/powerpc/pr65421-1.c | 6 ++ > gcc/testsuite/gcc.target/powerpc/pr65421.c | 33 +++++++++++ > 7 files changed, 129 insertions(+), 1 deletion(-) > create mode 100644 gcc/testsuite/gcc.target/powerpc/pr65421-1.c > create mode 100644 gcc/testsuite/gcc.target/powerpc/pr65421.c > > diff --git a/gcc/expr.cc b/gcc/expr.cc > index 15be1c8db99..97a7be9542e 100644 > --- a/gcc/expr.cc > +++ b/gcc/expr.cc > @@ -5559,6 +5559,41 @@ mem_ref_refers_to_non_mem_p (tree ref) > return non_mem_decl_p (base); > } > > +/* Sub routine of expand_assignment, invoked when assigning from a > + parameter or assigning to a return val on struct type which may > + be passed through registers. The mode of register is used to > + move the content for the assignment. > + > + This routine generates code for expression FROM which is BLKmode, > + and move the generated content to TO_RTX by su-blocks in SUB_MODE. */ > + > +static void > +move_sub_blocks (rtx to_rtx, tree from, machine_mode sub_mode) > +{ > + gcc_assert (MEM_P (to_rtx)); > + > + HOST_WIDE_INT size = MEM_SIZE (to_rtx).to_constant (); Consider the case of a BLKmode return value. Isn't TO_RTX in this case a BLKmode object? It looks pretty good at this point. jeff