[LLVMdev] Recursion inlining
pablo.barrio at arm.com
Mon Dec 22 08:44:36 PST 2014
I just realized I have sent an e-mail with an automatic disclaimer. Sorry about that. The contents of that e-mail are not confidential or privileged in any way.
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Pablo Barrio
Sent: 22 December 2014 15:45
To: Chandler Carruth
Cc: Jiangning Liu; LLVM Developers Mailing List
Subject: [LLVMdev] RFC: Recursion inlining
Thank you for the reply. I enabled recursion inlining in the current inliner and I already have some promising results. However, I found some trouble extending the current heuristics. I hope you can all give me some feedback.
First, context: the inliner is a CallGraphSCC pass. I detect recursion here by checking that, for each CallSite, the caller is the same as the callee (direct recursion) or at least both belong to the SCC currently being processed (indirect recursion). The decision whether to inline is taken in the InlineCost class, with the help of instruction visitor CallAnalyzer and some constants defined in namespace InlineConstants.
Now the problem. I want to use a different inline cost analysis for recursive functions. This might include a different/extended list of parameters (another InlineConstants namespace?) as well as a different cost function (CallAnalyzer), keeping the same InlineCost class. However, it is not possible to check if a function is recursive inside InlineCost, because it does not know about the SCC.
So my questions are:
- Shouldn't InlineConstants be part of the InlineCost class? It looks like they are intended to be used in all InlineCost analyses, but that might not be what we need.
- What would be the best way of making InlineCost aware that it is dealing with a "recursive callsite", this is, a callsite that closes a loop in the call graph? For now I have it hacked as a boolean passed from the Inliner, but it hurts my eyes every time I see it. Maybe let InlineCost know about about the current SCC? It would be easy if I could get the SCC that a function belongs to.
Another option would be to handle recursive function inlining in a separate Inliner pass, but the callgraph would not be traversed from the leaves to the root in a single pass.
Any thoughts, ideas, recommendations... will help.
From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: 05 December 2014 10:30
To: Pablo Barrio
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Recursion inlining
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...
More information about the llvm-dev