<div dir="ltr">Thx for the reply.<div>I've created <a href="https://bugs.llvm.org/show_bug.cgi?id=42254">https://bugs.llvm.org/show_bug.cgi?id=42254</a> and will work on a fix.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 11, 2019 at 6:08 PM JF Bastien <<a href="mailto:jfbastien@apple.com">jfbastien@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jun 11, 2019, at 6:27 AM, Guillaume Chatelet <<a href="mailto:gchatelet@google.com" target="_blank">gchatelet@google.com</a>> wrote:</div><br class="gmail-m_-2520815214115940705Apple-interchange-newline"><div><div dir="ltr">I spent some time reading the <a href="https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf" target="_blank">C standard</a>:<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>5.1.2.3 Program execution</div><div>2. Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any
of those operations are all side effects, which are changes in the state of the execution environment...</div></blockquote><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>6.7.3 Type qualifiers</div><div>8. An object that has volatile-qualified type may be modified in ways unknown to the implementation
or have other unknown side effects. Therefore any expression referring to such an object shall be
evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore,
at every sequence point the value last stored in the object shall agree with that prescribed by the
abstract machine, except as modified by the unknown factors mentioned previously. What
constitutes an access to an object that has volatile-qualified type is implementation-defined.</div></blockquote><div><br></div><div><div>My intuition is that it's unreasonable to do the overlap because it may create side effects in the middle of the read. At the same time, "accessing a volatile object" is implementation defined...</div><div>As such "volatile" does not provide a lot of guarantees. I guess you have to resort on assembly if you want to really control what's going on.<br></div><div><br></div><div>gcc, icc, msvc do not implement the overlap trick. They either read the memory region sequentially or use rep movs.</div><div>Let's note that rep movs does not provide any guarantees on the memory access patterns either.</div><div></div><div></div></div><div><br><div>Besides I'm not even sure that volatile in the context of @llvm.memcpy intrinsics really relates to the C volatile semantic.</div></div><div><br></div><div>Now, I see several ways to move forward:</div><div>1. Do nothing and call it implementation defined</div><div>2. Fix the code that generates the loads/stores for the isVolatile case so no overlap can occur.</div><div>3. Remove "volatile" argument from @llvm.memcpy, @llvm.memmove and @llvm.memset and generates the code in the front end using volatile load/stores.</div><div><br></div><div></div><div>3 is probably controversial and involves a lot a changes, it would move some complexity from backend to frontends.</div><div><br></div><div>I'm interested in thoughts from other developers here.</div></div></div></blockquote><div><br></div><div>Volatile isn’t specified in any decent normative way. There’s substantial documentation of intent, but C and C++ standards are lacking. We should therefore implement something that’s sensible and works kind-of as expected.</div><div><br></div><div>I’ve documented specification and intent here: <a href="http://wg21.link/P1152R0" target="_blank">wg21.link/P1152R0</a></div><div>If you want to follow-on (without all that documentation): <a href="http://wg21.link/P1152R1" target="_blank">wg21.link/P1152R1</a></div><div><br></div><div>I think we want option 2.: keep volatile memcpy, and implement it as touching each byte exactly once. That’s unlikely to be particularly useful for every direct-to-hardware uses, but it behaves intuitively enough that I think it’s desirable.</div><div><br></div><br><blockquote type="cite"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2019 at 10:51 PM John Regehr via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I agree, this is a bug.<br>
<br>
John<br>
<br>
<br>
On 6/7/19 11:48 AM, JF Bastien via llvm-dev wrote:<br>
> <br>
> <br>
>> On Jun 5, 2019, at 2:28 PM, Tim Northover via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> I don’t see any particular reason to guarantee that a volatile memcpy will access each byte exactly once. How is that useful?<br>
>><br>
>> I agree it's probably not that useful, but I think the non-duplicating<br>
>> property of volatile is ingrained strongly enough that viewing a<br>
>> memcpy as a single load and store to each unit (in an unspecified<br>
>> order) should be legitimate; so I think this actually is a bug.<br>
>><br>
>> As the documentation says though, it's unwise to depend on the<br>
>> behaviour of a volatile memcpy.<br>
> <br>
> I agree with Tim, this seems like a bug. My expectation is that volatile touch each memory location exactly once, unless absolutely impossible (e.g. bitfields on most ISAs).<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>