Re: volatile semantics

[Michael Veksler <VEKSLER@il.ibm.com>]

Gabriel Dos Reis wrote on 17/07/2005 06:07:29:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> | Anything it sees anything in a statement with volatile, it marks the
> | statement as volatile, which should stop things from touching it
> | (anything that *does* optimize something marked volatile is buggy).
> great!
>

I can't agree with that as is. I would refine it to:
  Anything that *does* optimizes away visible reads or writes of
  something marked volatile is buggy.

> | I should note that this will probably annoy the people who reported :
> |
> | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506
>
> The rationale is:
>
>    GCC doesn't know what constitutes a reference to a volatile memory,
>     so it never performs operations on them directly.  It will always
>     pull the value into a register first.

This can be optimized, without violating the rule for read/write
visibility. It was over a decade since I were on a Pentium validation
team, so I may be wrong:
  inc mem - without a LCK prefix is not atomic, generating a
  read, and then write - behaving as if it were 3 instructions:
  [read mem; inc; write mem].
What I am getting at, is that gcc is *allowed* to optimize any
sequence of the form [read mem; arithmetic; write mem] to
[arithmetic mem], even for a  volatile int.


I do *not* say that this *has* to be optimized, only that it could.
If it had to, gcc would have a very difficult time with RISC
load/store architectures. No reasonable interpretation of the
standard may claim that gcc *should* generate a single "inc y".
I claim that in this case gcc *could* generate a single "inc y",
and as such it is a missed optimization (and the PR is valid).

It may be a very difficult optimization to implement, so
it can be postponed indefinitely, but it should not be marked
INVALID. It should be marked a SUSPENDED missed
optimization opportunity (for x86 and probably several
other CISCs - as long as read/write is not atomic).


   Michael