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

[Eli Friedman via llvm-dev]

In general, the LangRef specification of “volatile” doesn’t specify how any particular memory access will be lowered.  This includes the number of memory accesses, the number of bytes accessed, and whether the accesses overlap.  That’s because it’s different for every target, depending on the available instructions.  The only universal guarantee is that volatile operations are emitted in source order relative to other volatile operations.  (See http://llvm.org/docs/LangRef.html#volatile-memory-accesses .)

For all in-tree targets, where possible, loads and stores with an appropriate scalar type and alignment will lowered to a single instruction.  Whether this applies to any particular combination of type/alignment depends on the subtarget.  For memcpy, or for loads and stores which can’t be lowered to a single instruction, we don’t promise to generate any particular sequence.

I don’t see any particular reason to guarantee that a volatile memcpy will access each byte exactly once.  How is that useful?

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Guillaume Chatelet via llvm-dev
Sent: Wednesday, June 5, 2019 6:36 AM
To: llvm-dev at lists.llvm.org
Subject: [EXT] [llvm-dev] @llvm.memcpy not honoring volatile?

The following IR with the volatile parameter set to true
> call void @llvm.memcpy.p0i8.p0i8.i64(i8* align 1 %0, i8* align 1 %1, i64 7, i1 true)

generates the following asm:
> movl    (%rsi), %eax
> movl    3(%rsi), %ecx
> movl    %ecx, 3(%rdi)
> movl    %eax, (%rdi)

It performs an overlapping read/write which - I believe - is violating the volatile semantic
Full example here: https://godbolt.org/z/P_rjBT

Is this a bug or am I misunderstanding volatile in this context?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190605/dbdbd8ec/attachment.html>