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

[Andrew Trick]

On Jan 29, 2013, at 11:40 AM, Jeffrey Yasskin <jyasskin at googlers.com> wrote:

> 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.

Thanks for the feedback. I moved the commentary to the commit log with your edits.
Committed r173974.
-Andy

>> 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
>>