<div dir="ltr">Hi Lang,<div><br></div><div>I reviewed the InstCombine side and it looks great, all that I ask is that you replace the `Instruction *` with `auto *` because the type is replicated in the `dyn_cast`.</div><div><br></div><div>My only concern is that clang will actually create calls to the memcpy intrinsic from within clang with pointers which exactly alias:</div><div><a href="http://clang.llvm.org/doxygen/CGExprAgg_8cpp_source.html#l01448">http://clang.llvm.org/doxygen/CGExprAgg_8cpp_source.html#l01448</a><br></div><div><br></div><div>I cannot confess to being an alias-analysis expert but my concern is that annotating the memcpy as such could create some interesting paradoxes. Those more familiar with AA should chime in.</div><div><br></div><div>I'm afraid I cannot provide any guidance on the SelectionDAG changes.</div><div><br></div><div>Thanks</div><div>-- </div><div>David Majnemer</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 10:06 PM, Lang Hames via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:13px">Another belated *ping*.</span><span class="HOEnZb"><font color="#888888"><br></font></span><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br><div class="gmail_quote">- Lang.</div></font></span><div><div class="h5"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 30, 2015 at 2:16 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Belated ping. :)<span><font color="#888888"><div><br></div><div>- Lang.</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 2:11 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Gentle ping.<span><font color="#888888"><div><br></div><div>- Lang.</div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 11:51 AM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ping / delayed reply.<div><br></div><div>DannyB - thanks for the extra context. :)</div><div><br></div><div>Chandler - any thoughts? Assuming you still want to keep this transform, what do you think of my instcombine change? (i.e. tagging the load/store pointers as non-aliasing for memcpy).</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 9:21 PM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wed, Apr 8, 2015 at 10:38 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:<br>
> On Wed, Apr 8, 2015 at 10:15 PM Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
>><br>
>> Hi David, Chandler,<br>
>><br>
>> The attached patch guts the SimplifyMemTransfer method, which turns small<br>
>> memcpys (1/2/4/8 bytes) into load/store pairs. Turning memcpys into<br>
>> load/store pairs loses information, since we can no longer assume the source<br>
>> and dest are non-overlapping. This is leading to some suboptimal expansions<br>
>> for small memcpys on AArch64 when -mno-unaligned-access is turned on (see<br>
>> r234462). I suspect other architectures would suffer similar issues.<br>
>><br>
>> I assume this transform is an old workaround to simplify other<br>
>> non-memcpy-aware IR transforms. These days I think most IR transforms can<br>
>> reason sensibly about memcpys, so I'm hoping this is safe to remove. FWIW,<br>
>> removing it didn't hit any regression tests except those that were verifying<br>
>> that this optimisation was being applied, but then you wouldn't really<br>
>> expect it to hit any others.<br>
><br>
><br>
> Heh. I tried to remove it before and it regressed a *lot* of performance.<br>
> Have you measured it? I think there are many places that don't today reason<br>
> about memcpy but do reason about loads and stores. Here is a partial list:<br>
><br>
> - GVN<br>
<br>
</span>Note:<br>
<br>
It reasons about memory intrinsics, including memcpy and memset, and<br>
will pull values out to forward.<br>
<br>
for memset, if the load is in the memset size, it will compute what<br>
the value is.<br>
For memcpy, it handles anything that is constant memory.<br>
<br>
<br>
(Certainly, loads and stores are handled better, but ...)<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>