<div dir="ltr">Hi Peter,<div class="gmail_extra"><br><div class="gmail_quote"><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>          I suspect that if you, Daniel B., and I were to have an in person meeting this would take 5~10 minutes</div><div>For everyone to (in terms D.B. will appreciate) “converge to a fixed point” (:-)! of understanding. Meanwhile we</div><div>are stuck with limited email bandwidth, but a meet-up at the next llvm Bay Area social might be a good idea.</div></div></blockquote><div><br></div><div>I'm not in the Bay Area, so I'm afraid email will have to do.</div><div> </div><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"><div>Whether GVN is an appropriate place for this opt is going to hinge on the precise details of the calling</div><div>Convention, which you are still being vague about. You are simultaneously saying</div><div>1) the memcpy are necessary</div><div>2) the memcpy can and should be opt away</div><div>But these two statements are mutually exclusive, so you need to be more precise about the CC.</div></div></blockquote><div><br></div><div>The question was not about a calling convention, the memcpys are explicit in the source language, but we'd like to give</div><div>some reasonable assurances that under appropriate circumstances, they'll go away in the optimizer. If you really want the</div><div>whole story in the source language you're welcome to read the appropriate design discussions. Some links with</div><div>various parts of the story.</div><div><br></div><div><a href="https://github.com/JuliaLang/julia/pull/21912">https://github.com/JuliaLang/julia/pull/21912</a></div><div><a href="https://github.com/JuliaLang/julia/issues/11902">https://github.com/JuliaLang/julia/issues/11902</a><br></div><div><a href="https://github.com/JuliaLang/julia/issues/11610">https://github.com/JuliaLang/julia/issues/11610</a><br></div><div><br></div><div><div>It's hard for me to assess how informative those links will be to people who haven't worked with julia a lot,</div></div><div>but that's the references we have anyway.</div><div> <br></div><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"><div>Why is this important?, because even if Daniel B. can enhance GVN to “look through” the memcpys</div><div>And optimize the loads from the local-stack-copy into loads through the original pointer argument,</div><div>And optimize the stores into the local-stack-copy into stores through the original pointer argument,</div><div>There is still the issue of deleting the memcpys themselves, which is the actual performance problem.</div><div><br></div><div>But the rules of the C/C++ programming language aren’t typically going to allow these deletions,</div><div>For example if the original pointer argument is passed to another function, or the address of any</div><div>Or all of the local stack copy are passed to another function, or simply calling *any* function because</div><div>It could by the C/C++ rules modify the original data, requiring the memcpys to be preserved.</div></div></blockquote><div><br></div><div>C/C++ semantics are not as important here as is whether the LLVM memory model allows this transformation.</div><div>We generate significantly stronger aliasing information in julia than clang does in most cases, so while this</div><div>clearly needs to be done with the appropriate legality checks on aliasing and memory order, I do believe the</div><div>transformation in the original example is allowable as given. If you think there's an argument that it is disallowed</div><div>according to current IR semantics, that's something I'd be most interested in.</div><div><br></div><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"><div>PS, Don’t be intimidated by writing an IR-to-IR pass, I’ve already written one, they are easy.</div><div>Yours will be particularly easy (after verifying the transform is legal) as it is just a “replace-all-</div><div>Uses-of” which already exists, deleting the memcpys, and finally deleting the stack object.</div></div></blockquote><div><br></div><div>That's certainly not the concern here. We've been doing this for many years now, so we'd be perfectly</div><div>comfortable writing our own pass. Nevertheless, as I mentioned before, we do try to make things generally</div><div>available when we can, and I feel that this is one of those situations. </div></div></div></div>