<div dir="ltr">Well, mostly I want to hoist the store to the stack and transform it into a store to the heap. After that the memcpys are essentially trivially dead, so instcombine or dse will delete them for me. If the memcpys were made of individual stores instead, there'd have to be some sort of exponential search somewhere in the compiler to figure that out. For the extreme case consider [100000000 x double]. The same optimization can apply here, but if it tried to do 100000000 stores instead, I wouldn't expect the compiler to really figure that out. What I meant was that I think the memcpys are the correct representation of this from the frontend, it's just that I'd like more optimization to happen here.<div><br></div><div><br><div class="gmail_extra"><div class="gmail_quote">On Wed, May 17, 2017 at 11:48 AM, Peter Lawrence <span dir="ltr"><<a href="mailto:peterl95124@sbcglobal.net" target="_blank">peterl95124@sbcglobal.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Keno,<div>          "No, I very much want the memcpys there” seems like a contradiction,</div><div>Aren’t you trying to optimize away the memcpys.</div><span class="gmail-HOEnZb"><font color="#888888"><div>Peter Lawrence</div></font></span><div><div class="gmail-h5"><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On May 17, 2017, at 8:22 AM, Keno Fischer <<a href="mailto:keno@juliacomputing.com" target="_blank">keno@juliacomputing.com</a>> wrote:</div><br class="gmail-m_703276034275331539Apple-interchange-newline"><div><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
</div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></div></div>