[llvm-dev] @llvm.memcpy not honoring volatile?

[Eli Friedman via llvm-dev]

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>