[llvm-dev] Volatile and Inserted Loads/Stores on MMIO

Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Wed Oct 10 18:12:41 PDT 2018


On 10/10/2018 4:27 PM, Taylor Cramer via llvm-dev wrote:
> The language reference 
> <https://llvm.org/docs/LangRef.html#volatile-memory-accesses> says 
> that LLVM optimizers must not change the number of volatile operations 
> or change their order of execution relative to other volatile 
> operations. However, it doesn't say that optimizers can't introduce 
> non-volatile operations. Is there any way to write IR that would 
> ensure the generated loads and stores exactly match the number and 
> ordering of the loads and stores in the source IR? I've heard 
> conflicting reports about this. I'm specifically interested in 
> manipulating MMIO, where loads and stores may have side effects.
>
> If it is in fact possible to prevent the insertion of loads/stores, 
> does the presence of the "dereferenceable" attribute on pointers have 
> any affect here? Will marking a pointer "dereferenceable" allow 
> loads/stores to a volatile-only-accessed memory location that wouldn't 
> be allowed otherwise?
>
> Context: this discussion originated in an issue on the Rust unsafe 
> code guidelines issue tracker 
> <https://github.com/rust-rfcs/unsafe-code-guidelines/issues/33>.

http://llvm.org/docs/LangRef.html#pointer-aliasing-rules says "Any 
memory access must be done through a pointer value associated with an 
address range of the memory access, otherwise the behavior is undefined."

 From LLVM's perspective, we can refer to all the memory which can 
possibly be accessed according to those rules as "allocated memory".  A 
non-volatile memory access can only access allocated memory.  MMIO 
registers are not allocated memory; they do not behave the way LLVM 
expects memory to behave.  So a non-volatile load from an MMIO register 
has undefined behavior.  And a pointer marked dereferenceable cannot 
point to an MMIO register, or the behavior is undefined.

volatile accesses are special; they have target-specific semantics, so 
they can access MMIO registers even though that isn't allowed for a 
non-volatile load.

In practice, this means your code will do what you want as long as all 
MMIO accesses are volatile.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181010/8eb20c15/attachment.html>


More information about the llvm-dev mailing list