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

[Chandler Carruth]

On Tue, Jan 29, 2013 at 11:21 AM, Andrew Trick <atrick at apple.com> wrote:

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

Indeed, footnotes would be lovely here.

There is always the commit log? Not really ideal...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130129/66c6798d/attachment.html>