<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Keno,<div class=""> Hmmm, seems like you are saying “copy-in-copy-out” argument semantics are required by the language,</div><div class="">Otherwise you would be using “by-reference" argument semantics,</div><div class="">And that CICO is easiest for you to represent with memcpy.</div><div class=""><br class=""></div><div class="">Usually there are some very subtle issues with CICO and the memory model,</div><div class="">Typically the original object isn’t supposed to be modified until the function returns,</div><div class="">IE multiple stores, especially of different values, to a field in the original object should not be visible, only the final store,</div><div class="">This is clearly “observable" in multithreaded programs, but can also be observable in a single threaded program</div><div class="">If the same object is visible from within the called function for example as a global variable</div><div class="">Which would be seen to have its internal values change multiple times, even though the</div><div class="">Intent of the language using CICO is to try to ensure all-at-once state changes (at least for single-threaded programs)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">My advice, if the above applies to you, is to add a new pass to the compiler that figures out if</div><div class="">The transformation from memcpy to explicit multiple load/store is actually legal (won’t produce intermediate</div><div class="">State changes before the exit of the function which would violate the strict CICO calling convention),</div><div class="">And also profitable (I don’t view the code explosion of [1000000 x double] as profitable!),</div><div class="">Or if the transformation from “CICO" to pure “by-reference” is both legal, and profitable.</div><div class=""><br class=""></div><div class="">(Also, don’t forget to check what the language spec says about this function passing the object,</div><div class="">Or parts of it, to other functions before or after making modifications)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">My advice regarding teaching GVN about memcpy is not to. It would be one thing if the memcpy</div><div class="">Were copying in/out a single variable, in that case the memcpy can and should be viewed as a load / store pair,</div><div class="">But in your case it isn’t being used that way, it is being used to copy multiple values, and the only</div><div class="">Logical thing that GVN could do is expand those out to multiple individual loads and stores. GVN should not</div><div class="">Be doing this, instead your new pass (that first checks to see if it is legal w.r.t. calling convention) is</div><div class="">The place to do this, or if should convert to pure “by-reference” if legal, which also shouldn’t be done in GVN.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">—Peter Lawrence.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 17, 2017, at 8:55 AM, Keno Fischer <<a href="mailto:keno@juliacomputing.com" class="">keno@juliacomputing.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class=""><br class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, May 17, 2017 at 11:48 AM, Peter Lawrence <span dir="ltr" class=""><<a href="mailto:peterl95124@sbcglobal.net" target="_blank" class="">peterl95124@sbcglobal.net</a>></span> wrote:<br class=""><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" class="">Keno,<div class=""> "No, I very much want the memcpys there” seems like a contradiction,</div><div class="">Aren’t you trying to optimize away the memcpys.</div><span class="gmail-HOEnZb"><font color="#888888" class=""><div class="">Peter Lawrence</div></font></span><div class=""><div class="gmail-h5"><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 17, 2017, at 8:22 AM, Keno Fischer <<a href="mailto:keno@juliacomputing.com" target="_blank" class="">keno@juliacomputing.com</a>> wrote:</div><br class="gmail-m_703276034275331539Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Wed, May 17, 2017 at 12:09 AM, Peter Lawrence via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">Keno,</div><div class=""> Perhaps you can view the problem to be the memcpys themselves,</div><div class="">We humans can look at the memcpys and see loads and stores</div><div class="">but to almost all optimizer passes they aren’t what it is looking for,</div><div class="">They instead see function calls which they mostly don’t touch,</div><div class=""><br class=""></div><div class="">If these memcpys were inlined into plain old loads and stores</div><div class="">The redundant loads and stores should be deleted by existing opts</div><div class=""><br class=""></div><div class="">A question I have for you is, because this looks like “copy-in-copy-out” argument semantics,</div><div class="">Which to me looks more like Ada than C, what was the source language ?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Peter Lawrence.</div></blockquote></div><br class="">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 class=""></div><div class="gmail_extra">Keno</div></div>
</div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></div></body></html>