public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Fei Gao" <gaofei@eswincomputing.com>
To: jeffreyalaw <jeffreyalaw@gmail.com>,
	 gcc-patches <gcc-patches@gcc.gnu.org>
Cc: "Kito Cheng" <kito.cheng@gmail.com>,
	 "Palmer Dabbelt" <palmer@dabbelt.com>,
	 Sinan <sinan.lin@linux.alibaba.com>,
	 jiawei <jiawei@iscas.ac.cn>
Subject: Re: Re: [PATCH 3/4] [RISC-V] resolve confilct between zcmp multi push/pop and shrink-wrap-separate
Date: Tue, 13 Jun 2023 10:35:53 +0800	[thread overview]
Message-ID: <20230613103553490495342@eswincomputing.com> (raw)
In-Reply-To: <d6259ea1-a645-dc7a-8397-b998aed561b8@gmail.com>

On 2023-06-13 03:26  Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
>On 6/6/23 23:52, Fei Gao wrote:
>> Disable zcmp multi push/pop if shrink-wrap-separate is active.
>>
>> So in -Os that prefers smaller code size, by default shrink-wrap-separate
>> is disabled while zcmp multi push/pop is enabled.
>>
>> And in -O2 and others that prefers speed, by default shrink-wrap-separate
>> is enabled while zcmp multi push/pop is disabled. To force enabling zcmp multi
>> push/pop in this case, -fno-shrink-wrap-separate has to be explictly given.
>>
>> The following TC shows the issues in -O2 before this patch with both
>> shrink-wrap-separate and zcmp multi push/pop active.
>> 1. duplicated store of s regs.
>> 2. cm.push pushes ra, s0-s11 in reverse order than what normal
>>     prologue does, causing stack corruption and failure to resotre s regs.
>>
>> TC: zcmp_shrink_wrap_separate.c included in this patch.
>>
>> output asm before this patch:
>> calc_func:
>> cm.push	{ra, s0-s3}, -32
>> ...
>> beq	a5,zero,.L2
>> ...
>> .L2:
>> ...
>> sw	s1,20(sp) //issue here
>> sw	s3,12(sp) //issue here
>> ...
>> sw	s2,16(sp) //issue here
>>
>> output asm after this patch:
>> calc_func:
>> addi	sp,sp,-32
>> sw	s0,24(sp)
>> ...
>> beq	a5,zero,.L2
>> ...
>> .L2:
>> ...
>> sw	s1,20(sp)
>> sw	s3,12(sp)
>> ...
>> sw	s2,16(sp)
>> gcc/ChangeLog:
>>
>>          * config/riscv/riscv.cc
>>          (riscv_avoid_shrink_wrapping_separate): wrap the condition check in
>>          riscv_avoid_shrink_wrapping_separate.
>>          (riscv_avoid_multi_push): avoid multi push if shrink_wrapping_separate
>>            is active.
>>          (riscv_get_separate_components): call riscv_avoid_shrink_wrapping_separate
>>          * shrink-wrap.cc (try_shrink_wrapping_separate): call
>>            use_shrink_wrapping_separate.
>>          (use_shrink_wrapping_separate):wrap the condition
>>            check in use_shrink_wrapping_separate
>>          * shrink-wrap.h (use_shrink_wrapping_separate): add to extern
>>
>> gcc/testsuite/ChangeLog:
>>
>>          * gcc.target/riscv/zcmp_shrink_wrap_separate.c: New test.
>>          * gcc.target/riscv/zcmp_shrink_wrap_separate2.c: New test.
>I know Kito asked for this to be broken up into target dependent vs
>target independent changes, that's a good ask.
>
>Can't we utilize the get_separate_components hook to accomplish what
>you're trying to do?  ie, put the logic to avoid shrink wrapping for
>this case within the existing risc-v hook? 

Thank Jeff and Kito for your comments. 

My first try was to avoid shrink wrapping if zcmp is enabled.
But after discussion with Kito and Andrew Pinski, I realized it's better to disable
zcmp push and pops if shrink wrapping is active.
For detailed discussion, please check link below.
thread: [PATCH 1/2] [RISC-V] disable shrink-wrap-separate if zcmp enabled.
link: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg307203.html

I will go ahead with Kito's advice if you're fine with the current solution.
Thanks.

BR, 
Fei


>
>jeff

  reply	other threads:[~2023-06-13  2:35 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-07  5:52 [PATCH 0/4] [RISC-V] support zcmp extention Fei Gao
2023-06-07  5:52 ` [PATCH 1/4][V4][RISC-V] support cm.push cm.pop cm.popret in zcmp Fei Gao
2023-06-07 10:11   ` jiawei
2023-08-16  8:33   ` Kito Cheng
2023-08-16  8:38     ` Kito Cheng
2023-08-16  9:03       ` Fei Gao
2023-08-20 10:53       ` Fei Gao
2023-08-28  8:04         ` Fei Gao
2023-08-17 11:39     ` Fei Gao
2023-06-07  5:52 ` [PATCH 2/4] [RISC-V] support cm.popretz " Fei Gao
2023-07-13  8:31   ` Kito Cheng
2023-06-07  5:52 ` [PATCH 3/4] [RISC-V] resolve confilct between zcmp multi push/pop and shrink-wrap-separate Fei Gao
2023-06-12 15:17   ` Kito Cheng
2023-06-12 19:26   ` Jeff Law
2023-06-13  2:35     ` Fei Gao [this message]
2023-06-07  5:52 ` [PATCH 4/4] [RISC-V] support cm.mva01s cm.mvsa01 in zcmp Fei Gao
2023-07-13  8:18   ` Kito Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230613103553490495342@eswincomputing.com \
    --to=gaofei@eswincomputing.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=jiawei@iscas.ac.cn \
    --cc=kito.cheng@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=sinan.lin@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).