public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Qing Zhao <qing.zhao@oracle.com>
To: Richard Sandiford <richard.sandiford@arm.com>
Cc: Xi Ruoyao <xry111@mengyan1223.wang>, Jeff Law <law@redhat.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	YunQiang Su <yunqiang.su@cipunited.com>,
	Jakub Jelinek <jakub@gcc.gnu.org>
Subject: Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817,  PR104820]
Date: Wed, 16 Mar 2022 20:27:26 +0000	[thread overview]
Message-ID: <B99DB0A3-1F79-48DC-98E3-30276B0EC3F4@oracle.com> (raw)
In-Reply-To: <mptsfrka5b3.fsf@arm.com>



> On Mar 14, 2022, at 11:04 AM, Richard Sandiford <richard.sandiford@arm.com> wrote:
> 
> Sorry for the slow response, was out for a few days.
> 
> Xi Ruoyao <xry111@mengyan1223.wang> writes:
>> On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote:
>>> On Fri, 2022-03-11 at 21:26 +0000, Qing Zhao wrote:
>>>> Hi, Ruoyao,
>>>> 
>>>> (I might not be able to reply to this thread till next Wed due to a
>>>> short vacation).
>>>> 
>>>> First, some comments on opening bugs against Gcc:
>>>> 
>>>> I took a look at the bug reports PR104817 and PR104820:
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820
>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
>>>> 
>>>> I didn’t see a testing case and a script to repeat the error, so I
>>>> cannot repeat the error at my side.
>>> 
>>> I've put the test case, but maybe you didn't see it because it is too
>>> simple:
>>> 
>>> echo 'int t() {}' | /home/xry111/git-repos/gcc-test-mips/gcc/cc1 -
>>> nostdinc -fzero-call-used-regs=all
>>> 
>>> An empty function is enough to break -fzero-call-used-regs=all.  And
>>> if
>>> you append -mips64r2 to the cc1 command line you'll get 104820.  I
>>> enabled 4 existing tests for MIPS (reported "not work" on MIPS) in the
>>> patch so I think it's unnecessary to add new test cases.
>>> 
>>> Richard: can we use MIPS_EPILOGUE_TEMP as a scratch register in the
>>> sequence for zeroing the call-used registers, and then zero itself
>>> (despite it's not in need_zeroed_hardregs)?
>> 
>> No, it leads to an ICE at stage 3 bootstrapping :(.
>> 
>> Now I think the only rational ways are:
>> 
>> (1) allow zeroing more registers than need_zeroed_hardregs.
> 
> I think this is the way to go.  I agree it's a bit hacky, but it seems
> like the least worst option.
> 
> A less hacky alternative would be to pass an extra argument to the hook
> that contains the set of registers that the hook is *allowed* to clobber.
> For -fzero-call-used-regs=X, this new argument would be the set that
> would have been chosen for -fzero-call-used-regs=all, regardless of
> what X actually is.  We could then assert that the extra registers we
> want to clobber are in that set (which will be true for all values of X).

If we have to go this way, I think it’s better to make the change you suggested above, 
and then also update the documentation, both internal documentation on how to define
 the hook and the user level documentation on what the user might expect when using 
this option (i.e, it’s possible that the compiler might clear more registers than the user 
requests on some targets due to the implementation limitation). 

I can make this change if we decide to do this.

Thanks.

Qing

> 
>> Or
>> 
>> (2) allow zeroing less registers than need_zeroed_hardregs (then I'll
>> skip ST_REGS, after all they are just 8 bits in total).
> 
> Yeah, this is explicitly OK, provided that the target maintainers
> feel that the contents of the registers in question are not a significant
> security concern.  I don't feel I can make that call though.  It's really
> a question for the userbase.
> 
> Thanks,
> Richard
> 
>> If all these are unacceptable, then
>> 
>> (3) I'll just call sorry in MIPS target hook to tell not to use this
>> feature on MIPS.


  parent reply	other threads:[~2022-03-16 20:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 20:40 Xi Ruoyao
2022-03-09 18:25 ` Richard Sandiford
2022-03-10 11:53   ` Xi Ruoyao
2022-03-10 13:41     ` [PATCH v2 " Xi Ruoyao
2022-03-10 13:45       ` [PATCH v2 RFC, resend] " Xi Ruoyao
2022-03-10 20:31   ` [PATCH RFC] " Qing Zhao
2022-03-11  2:54     ` Xi Ruoyao
2022-03-11 16:08       ` Qing Zhao
2022-03-11 17:29         ` Xi Ruoyao
2022-03-11 17:31           ` Xi Ruoyao
2022-03-11 21:26           ` Qing Zhao
2022-03-12 10:48             ` Xi Ruoyao
2022-03-13  6:03               ` Xi Ruoyao
2022-03-14 16:04                 ` Richard Sandiford
2022-03-14 17:05                   ` Xi Ruoyao
2022-03-16 20:27                   ` Qing Zhao [this message]
2022-03-18 13:11                     ` Xi Ruoyao
2022-03-18 16:09                       ` Richard Sandiford
2022-03-18 18:51                         ` Qing Zhao
2022-04-01 14:32           ` Maciej W. Rozycki

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=B99DB0A3-1F79-48DC-98E3-30276B0EC3F4@oracle.com \
    --to=qing.zhao@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@gcc.gnu.org \
    --cc=law@redhat.com \
    --cc=richard.sandiford@arm.com \
    --cc=xry111@mengyan1223.wang \
    --cc=yunqiang.su@cipunited.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).