public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Fei Gao <gaofei@eswincomputing.com>, gcc-patches@gcc.gnu.org
Cc: kito.cheng@gmail.com, palmer@dabbelt.com,
	sinan.lin@linux.alibaba.com, jiawei@iscas.ac.cn
Subject: Re: [PATCH 3/4] [RISC-V] resolve confilct between zcmp multi push/pop and shrink-wrap-separate
Date: Mon, 12 Jun 2023 13:26:48 -0600	[thread overview]
Message-ID: <d6259ea1-a645-dc7a-8397-b998aed561b8@gmail.com> (raw)
In-Reply-To: <20230607055215.29332-4-gaofei@eswincomputing.com>



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?

jeff

  parent reply	other threads:[~2023-06-12 19:26 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 [this message]
2023-06-13  2:35     ` Fei Gao
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=d6259ea1-a645-dc7a-8397-b998aed561b8@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gaofei@eswincomputing.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).