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: Mon, 24 Oct 2022 23:48:59 -0300 [thread overview]
Message-ID: <orczagvcro.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <66ECAC37-E763-4469-B31A-7A2B031026F4@oracle.com> (Qing Zhao's message of "Fri, 21 Oct 2022 14:26:13 +0000")
Hello, Qing,
It was a pleasure to meet you at the Cauldron.
On Oct 21, 2022, Qing Zhao <qing.zhao@oracle.com> wrote:
> Hi, Alexandre,
> Could you please explain a little bit on the motivation of this patch first?
It was a suggestion I got after the Cauldron presentation.
It made sense to me, and was easy enough to implement.
'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)
Though some functions are coded as leaf functions, others may become
leaf functions because of inlining or other optimizations. It's hard
for users to predict, so it makes sense to have a mode that tells the
compiler to figure it out.
There's room for a follow-up improvement, to save on a little more
potentially-wasteful anti-leaking scrubbing even in non-leaf functions:
for this purpose, they need not scrub registers that they don't use
themselves, if all potential callees are known to have scrubbed them.
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?)
I'm not entirely happy with leafy either, FWIW. Bikeshedding anyone? :-)
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604083.html
--
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>
next prev parent reply other threads:[~2022-10-25 2:49 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 [this message]
2022-10-25 15:22 ` Qing Zhao
2022-10-26 21:29 ` Alexandre Oliva
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=orczagvcro.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).