public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: "gcc-patches\@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs
Date: Wed, 26 Oct 2022 18:29:55 -0300	[thread overview]
Message-ID: <or5yg6gtnw.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <0DA25420-AE6D-418B-B2F6-7A99BCC34345@oracle.com> (Qing Zhao's message of "Tue, 25 Oct 2022 15:22:31 +0000")

On Oct 25, 2022, Qing Zhao <qing.zhao@oracle.com> wrote:

>> 'all' for leaf functions is likely wasteful.  If no other functions are
>> called, one can determine exactly which registers might carry
>> information out and thus need zeroing, and 'used' is thus likely enough,
>> depending on the purpose of register scrubbing.  (In some scenarios, it
>> might make sense to want scrubbing of all registers, even unused ones
>> that carry incoming values)

> Under what kinds of situations, we should clear the un-used registers
> for leaf functions?

The one (admittedly contrived) scenario that comes to mind is calling an
out-of-line, empty leaf function with 'all' for explicit register
scrubbing at desired points in the program.  I.e., this empty leaf
function would be in charge of scrubbing the caller's registers.  It
could even be tail-called.

I'm sure there are other scenarios in which keeping at least the
possibility of 'all' is useful.

> Now I am wondering whether we should make “leafy” mode by default then?

I'm not sure what you mean by default.  I think "skip" is the right
default for general use, where register scrubbing is not explicitly
requested.  When it is, perhaps -fzero-call-used-regs without
'=<choice>' could be 'leafy' indeed or, even better, the extended form
thereof that is in search of a name and so far unimplemented.

> Another thing is, do you have any information on how much this new mode can save the 
> code size and run-time compared to mode “all”?

I'm afraid I have not performed any measurements.

>> I have not (yet?) implemented this variant; I haven't even found a name
>> I'm happy with for it.  (seal?  plug?  cork?  another leak antonym?)

> For this improvement, I am still thinking no need to add a new mode,
> just add it by default?

Even if it is default, it may still need a name to appear before
e.g. '-gpr'.  'default-gpr' might do, but I'm not happy with it either.


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

  reply	other threads:[~2022-10-26 21:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  7:31 Alexandre Oliva
2022-10-21 14:26 ` Qing Zhao
2022-10-25  2:48   ` Alexandre Oliva
2022-10-25 15:22     ` Qing Zhao
2022-10-26 21:29       ` Alexandre Oliva [this message]
2022-10-27 13:30         ` Qing Zhao
2023-06-16  7:26           ` Alexandre Oliva
2023-06-16 19:34             ` Qing Zhao
2023-06-22  1:16               ` Alexandre Oliva
2023-06-23 14:47                 ` Qing Zhao
2023-06-23 23:27                   ` [PATCH v3] " Alexandre Oliva
2023-06-26 13:58                     ` Qing Zhao
2023-06-27  6:27                       ` Richard Biener

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=or5yg6gtnw.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=qing.zhao@oracle.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).