[llvm-commits] [llvm] r120974 - in /llvm/trunk: include/llvm/Analysis/AliasAnalysis.h lib/Transforms/Scalar/DeadStoreElimination.cpp test/Transforms/DeadStoreElimination/simple.ll

[Duncan Sands]

Hi Chris,

>> Aren't the operands of memcpy guaranteed not to overlap, so this would be undefined behaviour?
>
> Yes, sort of!  In practice, we allow memcpy's that overlap if the src/dst pointer is exactly the same.  This is because we want struct copies in C to be able to compile into memcpy, not memmove.  There is this code in Clang in CGExprAgg.cpp:
>
>    // Aggregate assignment turns into llvm.memcpy.  This is almost valid per
>    // C99 6.5.16.1p3, which states "If the value being stored in an object is
>    // read from another object that overlaps in anyway the storage of the first
>    // object, then the overlap shall be exact and the two objects shall have
>    // qualified or unqualified versions of a compatible type."
>    //
>    // memcpy is not defined if the source and destination pointers are exactly
>    // equal, but other compilers do this optimization, and almost every memcpy
>    // implementation handles this case safely.  If there is a libc that does not
>    // safely handle this, we can add a target hook.
>
> Note that the example from the PR doesn't explicitly call memcpy.

I've been told that on some platforms zeroing the target memory before doing the
copy speeds it up due to cache effects.  It looks like clang's implementation
of struct copy will not work on such targets.

Ciao,

Duncan.