The above logic makes sense when you're talking about non-volatile loads
and stores. To me, it doesn't make sense for volatile loads and stores.The whole point of volatile is to tell the compiler that its assumptions
about how memory works doesn't apply to this load or store and it
should, therefore, leave it alone and not do any optimization.
Informally, it's the programmer's way of telling the compiler, "I know
what I'm doing and you don't, so don't touch that memory operation."What you and Duncan are saying is that volatile is volatile except when
it isn't. I think that's poor design. At the very least, it is
confusing, and at worst, it prevents LLVM from handling C's "volatile"
keyword correctly.If it's decided that the current behavior is what LLVM will do, it
should at least be documented in the LLVM Language Reference Manual.
Right now, the current behavior directly contradicts the reference
manual, and that is definitely confusing.-- John T.
John,
On the one hand "volatile" it is to inform the compiler that either the "memory" being
referenced isn't really simple memory rather it is for example a device register with side-effects,
or that it is simple memory but holds a thread-shared global variable. On the other hand "volatile"
means don't delete, duplicate, reorder, or otherwise optimize references to this memory
location. But the latter is merely a convenient way to implement the necessary restrictions
required by the former, so who is to say that the implementation must dictate the definition ?
The documentation is simply telling you what a lazy implementation might do, not what
a system is required to do.
Your objection is like saying that it isn't kosher to ignore the "register" keyword, because
"I know what I am doing and you don't.....".
-Peter Lawrence.
