Unexpected clobber result from MemorySSA.

Hi all,

While porting MemCpyOpt to MemorySSA, I ran into some behavior that confounds
me. Consider the following pair of memcopies:

    %0 = type { ... }
    @global = external global %0

    define void @barney(%0* noalias sret %arg) nounwind {
      %tmp = alloca %0
      %tmp1 = bitcast %0* %tmp to i8*
      call void @llvm.memcpy.p0i8.p0i8.i32(i8* %tmp1, i8* bitcast (%0*
@global to i8*), i32 32, i32 16, i1 false) ; MemCpyInst *MDep;

                                             ; MemoryUseOrDef
MDepAccess = MSSA->getMemoryAccess(MDep);
      %tmp2 = bitcast %0* %arg to i8*
      call void @llvm.memcpy.p0i8.p0i8.i32(i8* %tmp2, i8* %tmp1, i32
32, i32 16, i1 false) ; MemCpyInst *M;

                     ; MemoryUseOrDef *MAccess =
      ret void

My goal is to find the closest memory instruction that clobbers the source
MemoryLocation of M, so I call:

    auto Source = MemoryLocation::getForSource(M);
    MemoryAccess *SourceClobber =
MSSA->getWalker()->getClobberingMemoryAccess(MAccess, Source);

I expect SourceClobber == MDepAccess. Instead, SourceClobber == MAccess. Making
the analogous query to MemDep does the right thing:

    MemDepResult SourceClobber =
MemDep->getPointerDependencyFrom(Source, false, M->getIterator(),

Here, SourceClobber.isClobber() == 1 and SourceClobber.getInst() == MDep.

getClobberingMemoryAccess is documented thusly:

    /// \brief Given a potentially clobbering memory access and a new location,
    /// calling this will give you the nearest dominating clobbering
    /// (by skipping non-aliasing def links).

So the semantics of this call is to search upwards for the nearest instruction
that clobbers Source, with one caveat: if the starting point (MAccess) itself
clobbers the passed location (Source), then MSSA will happily return that. In
other words, MSSA starts the upward clobber search at MAccess proper.

But LangRef specifically outlaws calling memcpy with overlapping locations, so
MAccess should never clobber Source. Right?

cc-ing Dan and George since they're the two MSSA experts I can think of. It
would be really great if either of you, or anyone else, could shed light on