Hi all, The default inliner currently marks all recursive functions as "never" inline when calculating the cost (CallAnalyzer::analyzeCall() in lib/Analysis/IPA/InlineCost.cpp). Is there any reason for this? Did anyone try to implement recursion inlining in the past and failed? Or succeeded, but it was dropped later on? All I found was a thread from a few years ago: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/043732.html I would expect some performance benefits in recursion inlining, obviously at the cost of code size increase. However, the heuristics could be tuned up so as to get a reasonable size/performance tradeoff. Many thanks, Pablo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141205/66949e6f/attachment.html>
On Fri, Dec 5, 2014 at 2:10 AM, Pablo Barrio <pablo.barrio at arm.com> wrote:> The default inliner currently marks all recursive functions as “never” > inline when calculating the cost (CallAnalyzer::analyzeCall() in > lib/Analysis/IPA/InlineCost.cpp). Is there any reason for this? >The reason used to be given in a comment in the code that got lost at some point. The idea is that inlining recursive calls is essentially loop unrolling. We need to model it's cost and effects more like loop unrolling intersected with inlining, and we don't really have a good model for that yet. It would be really nice to work up such a model, but would require loooots of benchmarking and careful tuning to find the right mixture. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141205/f6b4d284/attachment.html>