<div dir="ltr">Hi all,<div><br></div><div>Thanks for the quick response!</div><div><br></div><div>> <span style="line-height:1.5">This is not true if the program is not a C++ program.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Yes. It's a pretty egregious hack, and one that's been in the code since the year dot. Tests rely on it currently and I suppose people might rely on it when doing non-LTO builds... I'm happy removing it but the git blame commit log suggests this was tried before and people screamed.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> </span><span style="line-height:1.5">Thanks for working on this! Do you have any performance number?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Embarassingly, not all our test suites work with LTO yet so I don't have performance numbers from the test-suite. I have massive improvements (between 3% and 40%) in a third party benchmark suite that I can't mention the name of, and I expect this to hit spec2000::gcc too as it uses plenty of globals. Generally, older code suffering from "global soup" should get improvements from this.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> </span><span style="line-height:1.5">I am not sure if these conditions are sufficient to say the function does not recurse. Are indirect calls handled conservatively in the call graph?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">My belief was that yes, the CallGraph does indeed model indirect calls (specifically, if a function has its address taken or is external, it will have a special node calling it). I don't think what I have is sufficient though - I'll update the code. I'd forgotten about the case with indirect calls.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">> </span><span style="line-height:1.5">I imagine this property would be useful in other optimizations as well.</span></div>><br>>What about adding an LLVM attribute "norecurse" or some such?<div><br></div><div>Yes, that sounds like a good idea. Would you prefer me to hold this patch until I have implemented this, or is it OK to press ahead with this and swap the functionality over when the attribute is present? (adding attributes can take a while in my experience!)</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div><div><br><div><span style="line-height:1.5"><br></span></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 28 Oct 2015 at 18:00 Duncan P. N. Exon Smith via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 2015-Oct-28, at 09:45, Manman Ren <<a href="mailto:manman.ren@gmail.com" target="_blank">manman.ren@gmail.com</a>> wrote:<br>
><br>
> manmanren added a subscriber: manmanren.<br>
> manmanren added a comment.<br>
><br>
> Thanks for working on this!<br>
<br>
+1, I think it would be great to generalize this. Just one idea<br>
below...<br>
<br>
> Do you have any performance number?<br>
><br>
><br>
> ================<br>
> Comment at: lib/Transforms/IPO/GlobalOpt.cpp:100<br>
> @@ -90,2 +99,3 @@<br>
> SmallSet<const Comdat *, 8> NotDiscardableComdats;<br>
> + DenseMap<const Function *, bool> FunctionsKnownNotToRecurse;<br>
> };<br>
> ----------------<br>
> Comments will be great.<br>
> It is a little strange to name it "FunctionsKnownNotToRecurse" with a bool that tells if the function will recurse.<br>
<br>
I imagine this property would be useful in other optimizations as well.<br>
<br>
What about adding an LLVM attribute "norecurse" or some such?<br>
Assuming we can solve the indirect calls problem conservatively<br>
(e.g., should we be worried about function pointers escaping via<br>
atexit()?), this could be fairly easily propagated by an SCC pass.<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>