<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 17, 2017 at 12:09 AM, Peter Lawrence via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@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>Keno,</div><div>          Perhaps you can view the problem to be the memcpys themselves,</div><div>We humans can look at the memcpys and see loads and stores</div><div>but to almost all optimizer passes they aren’t what it is looking for,</div><div>They instead see function calls which they mostly don’t touch,</div><div><br></div><div>If these memcpys were inlined into plain old loads and stores</div><div>The redundant loads and stores should be deleted by existing opts</div><div><br></div><div>A question I have for you is, because this looks like “copy-in-copy-out” argument semantics,</div><div>Which to me looks more like Ada than C, what was the source language ?</div><div><br></div><div><br></div><div>Peter Lawrence.</div></blockquote></div><br>No, I very much want the memcpys there. With individual stores I'd give up hope that the optimizer can figure out what's going on here, esp. if it gets beyond a few bytes, but I with memcpys it does seem doable. As for which frontend produced this, we're considering adding language semantics that would produce lots of code like this to julia, so we're looking into getting the optimizer to fold the extra copies away.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Keno</div></div>