<div dir="auto"><div>Thanks for the response! I take from that that "dereferencable" isn't valid in reference to MMIO. It's still not clear to me, however, what part of the spec guarantees that extra non-volatile loads and stores to MMIO won't be inserted after llvm sees that a volatile load or store is guaranteed to be performed. Can you clarify that? Is that guarantee actually present? Additionally, is there something that clarifies the "special" behavior you refer to where volatile loads and stores need not operate on allocated memory in the same way that volatile loads and stores are expected to?<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 10, 2018, 6:12 PM Friedman, Eli <<a href="mailto:efriedma@codeaurora.org">efriedma@codeaurora.org</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="m_-6573715159400784880moz-cite-prefix">On 10/10/2018 4:27 PM, Taylor Cramer
      via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">The <a href="https://llvm.org/docs/LangRef.html#volatile-memory-accesses" target="_blank" rel="noreferrer">language reference</a> says
        that <span class="m_-6573715159400784880gmail-il">LLVM</span> 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.
        <div>
          <div><br>
          </div>
          <div>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?</div>
        </div>
        <div><br>
        </div>
        <div>Context: this discussion originated in <a href="https://github.com/rust-rfcs/unsafe-code-guidelines/issues/33" target="_blank" rel="noreferrer">an issue on the Rust
            unsafe code guidelines issue tracker</a>.</div>
      </div>
    </blockquote>
    <br>
    <a class="m_-6573715159400784880moz-txt-link-freetext" href="http://llvm.org/docs/LangRef.html#pointer-aliasing-rules" target="_blank" rel="noreferrer">http://llvm.org/docs/LangRef.html#pointer-aliasing-rules</a> 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."<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    In practice, this means your code will do what you want as long as
    all MMIO accesses are volatile.<br>
    <br>
    -Eli
    <pre class="m_-6573715159400784880moz-signature" cols="72">-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project</pre>
  </div>

</blockquote></div></div></div>