[PATCH] LangRef: Clarify expectations of volatile ld/st vs volatile intrinsics.

[Andrew Trick]

On Jan 29, 2013, at 11:09 AM, Chandler Carruth <chandlerc at google.com> wrote:

> On Tue, Jan 29, 2013 at 10:27 AM, Andrew Trick <atrick at apple.com> wrote:
> I was a bit worried that the memcpy/memmove intrinsic volatile flags could be misconstrued. Here's my attempt to clarify.
> Please review and feel free to suggest different wording...
> 
> Ahh, yes, I see the issue here.
> 
> 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....
> 
> 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.
> 
> How about just reducing this to the last bit:
> 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.
> 
> 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?

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. 

I'm ok stripping it down unless someone else argues to preserve the verbosity.
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130129/3a4fe50c/attachment.html>