[PATCH] D23937: [MemCpyOpt] Return value `memcpy` elision.

[bryant via llvm-commits]

bryant created this revision.
bryant added reviewers: eli.friedman, majnemer, rnk, aaron.ballman.
bryant added a subscriber: llvm-commits.
bryant set the repository for this revision to rL LLVM.

Clang (as opposed to clang++, which never exhibits this behavior due to NRVO)
tends to generate IR of the form (GEPs redacted for clarity),

```
%large = type { ... }
define void @f(%large* noalias sret, [remaining args]) {
  %retval = alloca %large
  [do stuff that stores to retval, possibly across several bb]
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %retval, i64 ..., i32 ..., i1 false)
  ret void
}
```

It's my understanding that if the sret is noalias: the memcpy could be elided,
the alloca removed, and all operations involving %retval and its computed
pointers replaced with the sret (and pointers computed thereof):

```
define void @f(%large* noalias sret, [remaining args]) {
  [do stuff that stores directly to %0]
  ret void
}
```

This patch augments `MemCpyOptPass` to do just that.

Fixes http://llvm.org/PR2218 .

Repository:
  rL LLVM

https://reviews.llvm.org/D23937

Files:
  lib/Transforms/Scalar/MemCpyOptimizer.cpp
  test/Transforms/MemCpyOpt/memcpy.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D23937.69402.patch
Type: text/x-patch
Size: 4371 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160826/938b6c78/attachment.bin>