<div dir="ltr">Gentle ping.<div><br></div><div>- Lang.</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 class="HOEnZb"><div class="h5"><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>