Gabriel Dos Reis wrote on 17/07/2005 06:07:29:
> Daniel Berlin <[EMAIL PROTECTED]> 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
