llvm dev - Jun 2019 - @llvm.memcpy not honoring volatile?

On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I don’t see any particular reason to guarantee that a volatile memcpy will
access each byte exactly once.  How is that useful?
I agree it's probably not that useful, but I think the non-duplicating
property of volatile is ingrained strongly enough that viewing a
memcpy as a single load and store to each unit (in an unspecified
order) should be legitimate; so I think this actually is a bug.

As the documentation says though, it's unwise to depend on the
behaviour of a volatile memcpy.

Cheers.

Tim.

Thx for the explanation Eli and Tim.
My understanding of volatile was that you may have a different value every
time you read and as such overlapping reads may be a bug.

Now, since the behaviour of volatile memcpy is not guaranteed and since clang
does not allow to use it anyways <https://godbolt.org/z/CnCOLc> I would
like to challenge its existence.
Is there a know reason for keeping the volatile argument in @llvm.memcpy?


On Wed, Jun 5, 2019 at 11:28 PM Tim Northover <t.p.northover at gmail.com>
wrote:
> On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I don’t see any particular reason to guarantee that a volatile memcpy
> will access each byte exactly once.  How is that useful?
>
> I agree it's probably not that useful, but I think the non-duplicating
> property of volatile is ingrained strongly enough that viewing a
> memcpy as a single load and store to each unit (in an unspecified
> order) should be legitimate; so I think this actually is a bug.
>
> As the documentation says though, it's unwise to depend on the
> behaviour of a volatile memcpy.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190606/22c38699/attachment.html>

The primary reason I don’t want to provide any guarantees for what instructions
are used to implement volatile memcpy is that it would forbid lowering a
volatile memcpy to a library call.

clang uses a volatile memcpy for struct assignment in C. For example, “void
f(volatile struct S*p) { p[0] = p[1]; }”.  It’s not really that useful, but it’s
been done that way since before clang was written.

-Eli

From: Guillaume Chatelet <gchatelet at google.com>
Sent: Thursday, June 6, 2019 2:40 AM
To: Tim Northover <t.p.northover at gmail.com>
Cc: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at
lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] @llvm.memcpy not honoring volatile?

Thx for the explanation Eli and Tim.
My understanding of volatile was that you may have a different value every time
you read and as such overlapping reads may be a bug.

Now, since the behaviour of volatile memcpy is not guaranteed and since clang
does not allow to use it anyways<https://godbolt.org/z/CnCOLc> I would
like to challenge its existence.
Is there a know reason for keeping the volatile argument in @llvm.memcpy?


On Wed, Jun 5, 2019 at 11:28 PM Tim Northover <t.p.northover at
gmail.com<mailto:t.p.northover at gmail.com>> wrote:
On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
wrote:
> I don’t see any particular reason to guarantee that a volatile memcpy will
access each byte exactly once.  How is that useful?
I agree it's probably not that useful, but I think the non-duplicating
property of volatile is ingrained strongly enough that viewing a
memcpy as a single load and store to each unit (in an unspecified
order) should be legitimate; so I think this actually is a bug.

As the documentation says though, it's unwise to depend on the
behaviour of a volatile memcpy.

Cheers.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190606/c9a4fba4/attachment.html>

> On Jun 5, 2019, at 2:28 PM, Tim Northover via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> I don’t see any particular reason to guarantee that a volatile memcpy
will access each byte exactly once.  How is that useful?
> 
> I agree it's probably not that useful, but I think the non-duplicating
> property of volatile is ingrained strongly enough that viewing a
> memcpy as a single load and store to each unit (in an unspecified
> order) should be legitimate; so I think this actually is a bug.
> 
> As the documentation says though, it's unwise to depend on the
> behaviour of a volatile memcpy.
I agree with Tim, this seems like a bug. My expectation is that volatile touch
each memory location exactly once, unless absolutely impossible (e.g. bitfields
on most ISAs).

I agree, this is a bug.

John


On 6/7/19 11:48 AM, JF Bastien via llvm-dev wrote:
> 
> 
>> On Jun 5, 2019, at 2:28 PM, Tim Northover via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>
>> On Wed, 5 Jun 2019 at 13:49, Eli Friedman via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> I don’t see any particular reason to guarantee that a volatile
memcpy will access each byte exactly once.  How is that useful?
>>
>> I agree it's probably not that useful, but I think the
non-duplicating
>> property of volatile is ingrained strongly enough that viewing a
>> memcpy as a single load and store to each unit (in an unspecified
>> order) should be legitimate; so I think this actually is a bug.
>>
>> As the documentation says though, it's unwise to depend on the
>> behaviour of a volatile memcpy.
> 
> I agree with Tim, this seems like a bug. My expectation is that volatile
touch each memory location exactly once, unless absolutely impossible (e.g.
bitfields on most ISAs).
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>