
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 29, 2013, at 11:09 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 style="">Ahh, yes, I see the issue here.</div><div style=""><br></div><div style="">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 style=""><br></div><div style="">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 style=""><br></div><div style="">How about just reducing this to the last bit:</div><div style=""><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 style="">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>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><br></div><div>I'm ok stripping it down unless someone else argues to preserve the verbosity.</div><div>-Andy</div></body></html>