<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Feb 26, 2016 at 8:44 PM Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- Original Message -----<br>
> From: "Chandler Carruth" <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
> Cc: "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"<br>
> <<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>>, "Xinliang David Li" <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>>, "Sanjoy Das" <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>><br>
> Sent: Friday, February 26, 2016 10:30:13 PM<br>
> Subject: Re: [llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")<br>
><br>
><br>
><br>
><br>
> On Fri, Feb 26, 2016 at 8:15 PM Hal Finkel < <a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a> > wrote:<br>
><br>
><br>
><br>
> Can you explain your concerns about reliability? My idea is that we<br>
> have a kind of delayed-name comdat section attribute that says that<br>
> the name of the comdat section into which the function will be<br>
> placed will be based on the hash of the contents (which should<br>
> probably be the pre-isel IR-level contexts plus perhaps the other<br>
> state that might affect backend optimization). Maybe just using the<br>
> MI-level function contents will work too. It seems like this should<br>
> be "perfect". I don't see the circumstances why function definitions<br>
> optimized under identical optimization settings should differ in<br>
> this sense.<br>
><br>
><br>
><br>
> Ok, let's consider Sanjoy's latest post.<br>
><br>
<br>
Indeed, a great example. His point is well taken, this is not strictly related to optimization level.<br>
<br>
><br>
> I think we could end up with this routine in N different modules with<br>
> slightly different amounts of information in each. Each of these in<br>
> turn could cause us to deduce a slightly different set of<br>
> attributes, and thus compute a different hash.<br>
><br>
> Now, certainly, there are a small number of variants here. Two, maybe<br>
> three. But this could in the worst case cause us to have two copies<br>
> of a *huge* number of functions.<br>
><br>
> My concern here is not that this is a *theoretically* hard problem to<br>
> solve. I think there are good techniques to handle this.<br>
<br>
It seems like, by definition, the information necessary to control the number of variants is not locally available. Controlling this by some global setting (opt for size vs. opt for speed) seems easy. Otherwise, I don't understand what you're thinking.<br></blockquote><div><br></div><div>I'm not speaking of controlling the variants, but of choosing appropriate thresholds for the potential size growth.</div><div><br></div><div>And yes, one input would obviously PGO, but there are others I suspect.</div></div></div>