Tim Northover via llvm-dev
2019-Jun-05 21:28 UTC
[llvm-dev] @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.
Guillaume Chatelet via llvm-dev
2019-Jun-06 09:40 UTC
[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> 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>
Eli Friedman via llvm-dev
2019-Jun-06 18:24 UTC
[llvm-dev] @llvm.memcpy not honoring volatile?
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>
JF Bastien via llvm-dev
2019-Jun-07 17:48 UTC
[llvm-dev] @llvm.memcpy not honoring volatile?
> 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).
John Regehr via llvm-dev
2019-Jun-10 20:51 UTC
[llvm-dev] @llvm.memcpy not honoring volatile?
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 >