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

[Chris Lattner]

On Dec 6, 2010, at 12:24 AM, Benjamin Kramer wrote:
On 06.12.2010, at 02:48, Chris Lattner wrote:
> 
>> Author: lattner
>> Date: Sun Dec  5 19:48:06 2010
>> New Revision: 120974
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=120974&view=rev
>> Log:
>> Fix PR8728, a miscompilation I recently introduced.  When optimizing
>> memcpy's like:
>> memcpy(A, B)
>> memcpy(A, C)
>> 
>> we cannot delete the first memcpy as dead if A and C might be aliases.
>> If so, we actually get:
> 
> 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.

-Chris