Sujet : Re: Computer architects leaving Intel...
De : tkoenig (at) *nospam* netcologne.de (Thomas Koenig)
Groupes : comp.archDate : 08. Sep 2024, 10:26:25
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vbjn3g$1s5b5$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
User-Agent : slrn/1.0.3 (Linux)
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.