From: Richard Biener <richard.guenther@gmail.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: Alexandre Oliva via Gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] hardened conditionals
Date: Mon, 18 Oct 2021 11:17:58 +0200 [thread overview]
Message-ID: <CAFiYyc0+FG+rSysOk+PhiAJem24JQqfEnaYLU0DE0s0TR3zsGQ@mail.gmail.com> (raw)
In-Reply-To: <orczo6jfvo.fsf@lxoliva.fsfla.org>
On Fri, Oct 15, 2021 at 8:35 PM Alexandre Oliva <oliva@adacore.com> wrote:
>
> On Oct 14, 2021, Richard Biener <richard.guenther@gmail.com> wrote:
>
> > Yeah, I think that eventually marking the operation we want to preserve
> > (with volatile?) would be the best way. On GIMPLE that's difficult,
> > it's easier on GENERIC (we can set TREE_THIS_VOLATILE on the
> > expression at least), and possibly also on RTL (where such flag
> > might already be a thing?).
>
> Making the expr volatile would likely get gimple to deal with it like
> memory, which would completely defeat the point of trying to avoid a
> copy.
>
> RTL has support for volatile MEMs and (user-)REGs indeed, but in order
> to avoid the copy, we don't want the pseudo to be volatile, we want
> specific users thereof to be. An unspec_volatile would accomplish that,
> but it would require RTL patterns to match it wherever a pseudo might
> appear. Considering all forms of insns involving conditionals on all
> relevant targets, that's far too much effort for no measurable beenefit.
>
>
> > So when going that way doing the hardening on RTL seems easier (if you
> > want to catch all compares, if you want to only catch compare + jump
> > that has your mentioned issue of all the different representations)
>
> It's not. RTL has various ways to represent store-flags too. Even now
> that we don't have to worry about implicit CC, a single boolean test may
> expand to a compare-and-set-[CC-]reg, and then a
> compare-and-store-CC-reg, or a single compare-and-set-[non-CC-]reg, and
> IIRC in some cases even more than one (pair of) conditionals.
>
> Compare-and-branches also come in such a multitude of settings.
>
> It all depends on the target, and I don't really see any benefit
> whatsoever of implementing such trivial gimple passes with all the
> potential complexity of RTL on all the architectures relevant for GCC,
> or even for this project alone.
>
> > Note that I did not look on the actual patch, I'm trying to see whether there's
> > some generic usefulness we can extract from the patchs requirement
> > which to me looks quite specific and given it's "hackish" implementation
> > way might not be the most important one to carry on trunk (I understand
> > that AdaCore will carry it in their compiler).
>
> It's also simple, no-maintenance, and entirely self-contained.
Yes, it is (just having had a quick look most of the functions in the
pass lack function-level comments).
> A good
> example of something that could be implemented as a plugin, except for
> command-line options.
>
> Maybe we could have a plugin collection in our source tree, to hold
> stuff like this and to offer examples of plugins, and means to build
> select plugins as such, or as preloaded modules into the compiler for
> easier deployment.
I think this has been suggested before, yes. But if those "plugins"
are as self-contained as yours here there's also no reason to not
simply compile them in as regular passes (unless they are slightly
broken and thus a maintainance burden).
Richard.
> --
> 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:[~2021-10-18 9:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 3:30 Alexandre Oliva
2021-10-09 6:42 ` Richard Biener
2021-10-12 6:35 ` Alexandre Oliva
2021-10-12 12:23 ` Richard Biener
2021-10-13 18:54 ` Alexandre Oliva
2021-10-14 7:49 ` Richard Biener
2021-10-15 18:35 ` Alexandre Oliva
2021-10-18 9:17 ` Richard Biener [this message]
2021-10-20 8:50 ` Alexandre Oliva
2021-10-22 2:19 ` Alexandre Oliva
2021-10-26 8:21 ` Richard Biener
2021-10-28 4:04 ` Alexandre Oliva
2021-10-30 9:44 ` Alexandre Oliva
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=CAFiYyc0+FG+rSysOk+PhiAJem24JQqfEnaYLU0DE0s0TR3zsGQ@mail.gmail.com \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=oliva@adacore.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).