Linus Torvalds wrote:
> Nope. "memory" fills that role too. Remember: "memory" doesn't actually
> say "this clobbers all memory". That would be silly: an asm that just
> wipes all memory would not be a very useful asm (or rather, it would have
> just _one_ use: "execve()"). So "memory" really says that the asm clobbers
> _some_ memory.
>
> Which in turn means that the code scheduler has to synchronize all memory
> accesses around it - as if the asm was reading all memory. Because if the
> scheduler would move a store to after the asm, it would give the wrong
> results if the asm happened to clobber _that_ memory. And the scheduler
> obviously cannot just drop the store ("Oh, the asm will clobber this
> anyway"), because it doesn't know which memory regions get clobbered.
There are other reasons why stores can be eliminated, and "memory" does
not prevent those.
Example: you have two stores to the same address. An "asm" with
"memory" is in between the stores.
The first store can still be dropped, even though we don't know _which_
memory the "memory" clobbers.
Now, "memory" may well mean "this asm is considered to read some memory
and clobber some memory". But that's not what the manual says, and it
would be inconsistent with other kinds of clobber.
> Now, the fact that the "memory" clobber also seems to clobber local
> variables is a bug, I think.
If you are thinking of my examples, "memory" doesn't clobber local
variables. It does affect the scheduling of reads from general memory
into a local variable.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:30 EST