
<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Hal Finkel via llvm-dev" <llvm-dev@lists.llvm.org><br><b>To: </b>"Xinliang David Li" <xinliangli@gmail.com><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org><br><b>Sent: </b>Friday, February 26, 2016 11:07:35 PM<br><b>Subject: </b>Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br><br>

<style>p { margin: 0; }</style><div id="DWT15820" style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Xinliang David Li" <xinliangli@gmail.com><br><b>To: </b>"Hal Finkel" <hfinkel@anl.gov><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org>, "Philip Reames" <listmail@philipreames.com>, "Duncan P. N. Exon Smith" <dexonsmith@apple.com>, "Sanjoy Das" <sanjoy@playingwithpointers.com>, "Chandler Carruth" <chandlerc@google.com><br><b>Sent: </b>Friday, February 26, 2016 10:59:40 PM<br><b>Subject: </b>Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 8:57 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br><br><hr><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Xinliang David Li" <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>><br><b>To: </b>"Chandler Carruth" <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>><br><b>Cc: </b>"Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "Philip Reames" <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>>, "Duncan P. N. Exon Smith" <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>>, "Sanjoy Das" <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>><br><b>Sent: </b>Friday, February 26, 2016 10:48:13 PM<span class=""><br><b>Subject: </b>Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br><br></span><div dir="ltr"><br><div class="gmail_extra"><br><span class=""><div class="gmail_quote">On Fri, Feb 26, 2016 at 8:43 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Fri, Feb 26, 2016 at 8:40 PM Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 26, 2016 at 8:30 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Fri, Feb 26, 2016 at 8:15 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">Can you explain your concerns about reliability? My idea is that we have a kind of delayed-name comdat section attribute that says that the name of the comdat section into which the function will be placed will be based on the hash of the contents (which should probably be the pre-isel IR-level contexts plus perhaps the other state that might affect backend optimization). Maybe just using the MI-level function contents will work too. It seems like this should be "perfect". I don't see the circumstances why function definitions optimized under identical optimization settings should differ in this sense.<br></div></div></blockquote><div><br></div></span><div>Ok, let's consider Sanjoy's latest post.</div><div><br></div><div>I think we could end up with this routine in N different modules with slightly different amounts of information in each. Each of these in turn could cause us to deduce a slightly different set of attributes, and thus compute a different hash.</div><div><br></div><div>Now, certainly, there are a small number of variants here. Two, maybe three. But this could in the worst case cause us to have two copies of a *huge* number of functions.</div><div><br></div><div>My concern here is not that this is a *theoretically* hard problem to solve. I think there are good techniques to handle this. My concern is that it will be a substantial amount of work and require a reasonable amount of testing and experimentation.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Such data won't be too hard to find out. It can be conservatively estimated by looking at the final binary code for each COMDAT to see how many 'clones's are needed due to different code gen -- the result is the upper bound as different code gen does not mean different deduced function attributes.</div><div><br></div><div>With PGO, the decision process will also become much simpler.</div></div></div></div></blockquote><div><br></div></span><div>Sure. And if you want to work on privatization in LLVM's IPO, that would be awesome.</div><div><br></div><div>But I think it is completely unreasonable to gate checking in code to test for the invalid transformation until this new optimization technique is available. We should be fixing the bug now, and then figuring out how to do privatization.</div></div></div></blockquote><div><br></div><div>Isn't privatization one way to get correctness? Other techniques such as hash based de-dup or use PGO etc for tuning are orthognal methods to reduce the overall cost of the former.</div></div></span></div></div></blockquote><br>It is, and I agree. However, the code-size growth seems like it could easily be unacceptable even for speed-optimized builds without the kind of mitigation options mentioned.<br></div></div></blockquote><div><br></div><div id="DWT15705">Except that there might be icache/itlb impact so performance is not totally immune to size increase -- otherwise we may as well just force inlining those :)</div></div></div></div></blockquote><br>This is why I am hoping we can aggressively apply that kind of privatization. However, it might turn out not to be the case.<br></div></blockquote>But to be clear, my point is that (at least when optimizing for speed), we should try this when fixing the bug. It might turn out we can't afford the size increase, but we need to make a quantitative decision on that. If we can deal with the increase, then it seems like we can then work on recovering the code-size losses using the mechanisms discussed. These might require tuning to be acceptable, or the tuning might itself be an extra nicety to further recover code size regressions.<br><br>I'm assuming here that privatization can be accomplished simply by switching the linkage on the current function (although do we need to do something special for function pointers?), and so the implementation cost is not high.<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br> -Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt; color: rgb(0, 0, 0);"><br> -Hal<br><br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div><div>David </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr"><div class="gmail_quote"><span><font color="#888888"><div><br></div><div>-Chandler</div></font></span></div></div>

</blockquote></div><br></div></div>

</blockquote><span class=""><br><br><br>-- <br><div><span></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span></span><br></div></span></div></div></blockquote></div><br></div></div>

</blockquote><br><br><br>-- <br><div><span></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span></span><br></div></div><br>_______________________________________________<br>LLVM Developers mailing list<br>llvm-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>