<div dir="ltr">On Tue, Jan 29, 2013 at 11:21 AM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank" class="cremed">atrick@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Jan 29, 2013, at 11:09 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank" class="cremed">chandlerc@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 29, 2013 at 10:27 AM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank" class="cremed">atrick@apple.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I was a bit worried that the memcpy/memmove intrinsic volatile flags could be misconstrued. Here's my attempt to clarify.<br>


Please review and feel free to suggest different wording...<br></blockquote><div><br></div><div>Ahh, yes, I see the issue here.</div><div><br></div><div>However, I'd like to suggest different wording to (hopefully!) achieve the same result. Specifically, I'm worried both about the mention of C semantics in the langref and the mention of the word 'atomic' in a section about volatiles, and I suspect with a more fundamental meaning than the special meanings we assign 'atomic' in concurrent contexts....</div>

<div><br></div><div>I also worry because I'm not sure it's reasonable to mandate i8 lowering of volatile memset or memcpy -- why not some other bitwidth? I feel like the only guarantee we have with a volatile memset or memcpy is that each byte in the destination (and source) get's touched exactly once.</div>

<div><br></div><div>How about just reducing this to the last bit:</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

IR-level volatile loads and stores cannot safely be optimized into llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are volatile. Likewise, the backend should never split or merge target-legal volatile load/store instructions.</blockquote>

<div><br></div><div>This essentially makes explicitly sized volatile loads and stores more protected constructs than the intrinsics, which I think is the desired end state, and is conservatively correct for the frontends I know of. Thoughts?</div>

</div></div></div></div>
</blockquote></div><br></div></div><div>Yes. That part is all we need for the spec. But I personally hate it when someone tells me to follow a rule and doesn't explain why. Unfortunately, the terminology can be tricky (for me at least), If we had some notion of footnotes, I would put the explanation there.</div>
</div></blockquote><div><br></div><div style>Indeed, footnotes would be lovely here.</div><div style><br></div><div style>There is always the commit log? Not really ideal...</div></div></div></div>