From: Michael Matz <matz@suse.de>
To: Martin Uecker <ma.uecker@gmail.com>
Cc: Jonathan Wakely <jwakely.gcc@gmail.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: reordering of trapping operations and volatile
Date: Mon, 17 Jan 2022 14:10:22 +0000 (UTC) [thread overview]
Message-ID: <alpine.LSU.2.20.2201171338100.4251@wotan.suse.de> (raw)
In-Reply-To: <7ff97dbb30d440aeed9e338847af41dd55cd3ed9.camel@gmail.com>
Hello,
On Sat, 15 Jan 2022, Martin Uecker wrote:
> > Because it interferes with existing optimisations. An explicit
> > checkpoint has a clear meaning. Using every volatile access that way
> > will hurt performance of code that doesn't require that behaviour for
> > correctness.
>
> This is why I would like to understand better what real use cases of
> performance sensitive code actually make use of volatile and are
> negatively affected. Then one could discuss the tradeoffs.
But you seem to ignore whatever we say in this thread. There are now
multiple examples that demonstrate problems with your proposal as imagined
(for lack of a _concrete_ proposal with wording from you), problems that
don't involve volatile at all. They all stem from the fact that you order
UB with respect to all side effects (because you haven't said how you want
to avoid such total ordering with all side effects).
As I said upthread: you need to define a concept of time at whose
granularity you want to limit the effects of UB, and the borders of each
time step can't simply be (all) the existing side effects. Then you need
to have wording of what it means for UB to occur within such time step, in
particular if multiple UB happens within one (for best results it should
simply be UB, not individual instances of different UBs).
If you look at the C++ proposal (thanks Jonathan) I think you will find
that if you replace 'std::observable' with 'sequence point containing a
volatile access' that you basically end up with what you wanted. The
crucial point being that the time steps (epochs in that proposal) aren't
defined by all side effects but by a specific and explicit thing only (new
function in the proposal, volatile accesses in an alternative).
FWIW: I think for a new language feature reusing volatile accesses as the
clock ticks are the worse choice: if you intend that feature to be used
for writing safer programs (a reasonable thing) I think being explicit and
at the same time null-overhead is better (i.e. a new internal
function/keyword/builtin, specified to have no effects except moving the
clock forward). volatile accesses obviously already exist and hence are
easier to integrate into the standard, but in a given new/safe program,
whenever you see a volatile access you would always need to ask 'is thise
for clock ticks, or is it a "real" volatile access for memmap IO'.
Ciao,
Michael.
next prev parent reply other threads:[~2022-01-17 14:10 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-08 8:32 Martin Uecker
2022-01-08 12:41 ` Richard Biener
2022-01-08 13:50 ` Martin Uecker
2022-01-08 14:13 ` Marc Glisse
2022-01-08 14:41 ` Eric Botcazou
2022-01-08 15:27 ` Martin Uecker
2022-01-08 17:33 ` Eric Botcazou
2022-01-08 15:03 ` David Brown
2022-01-08 16:42 ` Martin Uecker
2022-01-08 18:35 ` Andrew Pinski
2022-01-08 21:07 ` Martin Uecker
2022-01-10 9:04 ` Richard Biener
2022-01-10 17:36 ` Martin Uecker
2022-01-11 7:11 ` Richard Biener
2022-01-11 8:17 ` Martin Uecker
2022-01-11 9:13 ` Richard Biener
2022-01-11 20:01 ` Martin Uecker
2022-01-13 16:45 ` Michael Matz
2022-01-13 19:17 ` Martin Uecker
2022-01-14 14:15 ` Michael Matz
2022-01-14 14:58 ` Paul Koning
2022-01-15 21:28 ` Martin Sebor
2022-01-15 21:38 ` Paul Koning
2022-01-16 12:37 ` Martin Uecker
2022-01-14 15:46 ` Martin Uecker
2022-01-14 19:54 ` Jonathan Wakely
2022-01-15 9:00 ` Martin Uecker
2022-01-15 16:33 ` Jonathan Wakely
2022-01-15 18:48 ` Martin Uecker
2022-01-17 14:10 ` Michael Matz [this message]
2022-01-18 8:31 ` Richard Biener
2022-01-21 16:21 ` Martin Uecker
2022-01-11 18:17 ` David Brown
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=alpine.LSU.2.20.2201171338100.4251@wotan.suse.de \
--to=matz@suse.de \
--cc=gcc@gcc.gnu.org \
--cc=jwakely.gcc@gmail.com \
--cc=ma.uecker@gmail.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).