Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 8 Sep 2024 08:26:25 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <vbjn3g$1s5b5$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at>
 <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me>
 <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb3k0m$1rth7$1@dont-email.me>
 <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org>
 <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com>
 <86r0a2otte.fsf@linuxsc.com> <vb50cm$2uttr$1@dont-email.me>
 <vb58i5$303nc$1@dont-email.me> <868qw4oqd2.fsf@linuxsc.com>
 <vbgv7r$18q47$1@dont-email.me> <864j6qncib.fsf@linuxsc.com>
Injection-Date: Sun, 08 Sep 2024 10:26:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d7ba24bf9b685bf0d6c797373a0fc93a";
	logging-data="1971557"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+1Io8OkfYUfZITtB5qOwKe4a1NFaQl6uE="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:3chnWQu+iCMN4fF2i23eQY48dSw=
Bytes: 4001

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:

>> After thinking about this for a time, what you want looks a lot
>> like volaitle.
>
> That's a good insight.  Certainly there are aspects of what I
> have proposed that are similar to how volatile works.

The way I understand you is the following: You want the
compiler to be forbidden to remove codepaths on the assumption
that undefined behavior cannot happen, and you want a
"best effort" in that case, which includes throwing an error
or just ignoring everything and proceeding.

The observable behavior includes (n2596)

"Volatile accesses to objects are evaluated strictly according to
the rules of the abstract machine."

So, assuming that variables are objects (if there's a definition
of an object in n2596, I missed it) the compiler cannot remove
accessing a in

   volatile int a;

   if (a > a + 1)

so it cannot remove any code path leading to the if statement, which
is what you want.  An interesting point is what "volatile access"
actually means, especially for automatic variables; it seems that
all compilers treat this as a memory access (which makes limited
sense in my opinion - is there an explanation for this?)

>
>> Is there any requirement that you can think of that would not
>> be fullfilled with "volatile int a"?
>>
>> Is there anything with "volatile int a" that you do not want?
>
> Something being volatile has consequences only in reference to
> objects, and only when a memory access (either read or write) is
> requested.  There are no such things as volatile values.  What
> we're looking for here is constraints on operations, not on
> memory accesses.  In a sense one might say what we want is
> "volatile operators":  similar in concept to how volatile works,
> but in a different area of language semantics.

Hmm.. OK. The nice thing about SSA is that it transforms 
complicated expressions like "a + b + c" into

tmp1 = a + b
tmp2 = tmp1 + c

so it would be possible to write a pass which would declare those
variables as volatile that you want (not needed for unsigned, for
example). 

Alternatively, you could write a pass which translates

  int a, b;

  tmp1 = a + b;

into

  tmp1 = (int) ((unsigned) a + (unsigned) b)

or just use -frwapv in the first place.

So, SSA offers you the possibility of working on operators, like
you want to.