<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 10/11/2018 12:26 AM, Taylor Cramer via llvm-dev wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAFVyvB+a5m-egDUceGBnjvcC+M7kMZy8TxgG_gqZTGGTPCLvcw@mail.gmail.com">
<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?</div>
</div>
</blockquote>
<br>
I don't believe that the LangRef provides that guarantee. We probably should because, from a hardware perspective, there's likely no difference between volatile and non-volatile accesses so adding more non-volatile accesses is equivalent, practically, to adding
more volatile accesses. It's also not immediately obvious to me that llvm::FindAvailablePtrLoadStore and llvm::isSafeToLoadUnconditionally skip volatile accesses when scanning, so at least in theory care is needed on this front.<br>
<br>
<blockquote type="cite" cite="mid:CAFVyvB+a5m-egDUceGBnjvcC+M7kMZy8TxgG_gqZTGGTPCLvcw@mail.gmail.com">
<div dir="auto">
<div>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>
</div>
</div>
</blockquote>
<br>
It's not clear to me that this is needed. MMIO regions can be viewed as allocated by the system.<br>
<br>
-Hal<br>
<br>
<blockquote type="cite" cite="mid:CAFVyvB+a5m-egDUceGBnjvcC+M7kMZy8TxgG_gqZTGGTPCLvcw@mail.gmail.com">
<div dir="auto">
<div><br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Oct 10, 2018, 6:12 PM Friedman, Eli <<a href="mailto:efriedma@codeaurora.org" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset> <br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>