[PATCH] [MemCpyOpt] Turn memcpy from just-memset'd source into memset.

[Daniel Berlin]

SGTM.
It is almost zero cost to check and optimize this case, so if it
actually happens, i'm fine with it.

I did get around to testing, and it's definitely the case that GVN is
much happier with them as memsets.  It can often pull the constant
value directly out of the memset, whereas when they are memcpy, it
often just ends up with a use of a load or a load widening.


On Tue, May 12, 2015 at 2:49 PM, Ahmed Bougacha
<ahmed.bougacha at gmail.com> wrote:
> REPOSITORY
>   rL LLVM
>
> ================
> Comment at: lib/Transforms/Scalar/MemCpyOptimizer.cpp:931
> @@ -901,1 +930,3 @@
> +}
> +
>  /// processMemCpy - perform simplification of memcpy's.  If we have memcpy A
> ----------------
> dberlin wrote:
>> So, this looks like a valid optimization, and in fact, i expect things like GVN would like this form better than the original.
>>
>> But I am curious how often it actually happens.
>>
>> Do you have real programs where this triggers?
>>
> From clang, I don't think it happens very often.
>
> I saw this on C++ move constructors implemented in terms of std::swap.  For instance:
>
>
> ```
> #include <string>
> #include <utility>
>
> struct A {
>   std::string a;
>   A(A &&other);
> };
>
> A::A(A &&other)  {
>   std::swap(a, other.a);
> }
> ```
>
> Which I think is a controversial idiom in the C++ world, but still gets written ;)
> It's also easy to have an artificial testcase:
>
>
> ```
> void bar(int *);
>
> struct B {
>   int b[100];
>   B() : b() {}
> };
>
> void foo() {
>   B x;
>   B y = x;
>   bar(x.b);
>   bar(y.b);
> }
> ```
>
> But I can't say I've seen that one (not that I looked; perhaps I should).
>
> http://reviews.llvm.org/D9682
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>