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

[Jeffrey Yasskin]

On Tue, 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....

s/atomic/implemented with a single machine instruction/ probably makes
it correct, since it's already talking about platforms. However, I
believe "likely holds for l-values of volatile primitive types" is
*not* true for int64 on x86-32.

I wonder if there should be an LLVM doc for each backend that
specifies how volatiles of each size are lowered. It can't be in the
LangRef because it's too target-dependent, but kernel and
device-driver authors do depend on it.

> 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?
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>