[LLVMdev] LLVMdev Digest, Vol 76, Issue 43

[Peter Lawrence]

>
> 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.