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

[Chandler Carruth]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130129/42f8152b/attachment.html>