[llvm-commits] [llvm] r164207 - in /llvm/trunk: include/llvm/Analysis/InlineCost.h lib/Analysis/InlineCost.cpp test/Transforms/Inline/recurseive.ll

[Nadav Rotem]

Hi Nick!

Thanks for the feedback. 

>> 
> 
> Typo in test name.
> 

Fixed.

>> Modified:
>>     llvm/trunk/include/llvm/Analysis/InlineCost.h
>>     llvm/trunk/lib/Analysis/InlineCost.cpp
>> 
>> Modified: llvm/trunk/include/llvm/Analysis/InlineCost.h
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Analysis/InlineCost.h?rev=164207&r1=164206&r2=164207&view=diff
>> ==============================================================================
>> --- llvm/trunk/include/llvm/Analysis/InlineCost.h (original)
>> +++ llvm/trunk/include/llvm/Analysis/InlineCost.h Wed Sep 19 03:08:04 2012
>> @@ -36,6 +36,9 @@
>>      const int LastCallToStaticBonus = -15000;
>>      const int ColdccPenalty = 2000;
>>      const int NoreturnPenalty = 10000;
>> +    /// Do not inline functions which allocate this many bytes on the stack
>> +    /// when the caller is recursive.
>> +    const int TotalAllocaSizeRecursiveCaller = 1024;
> 
> Fundamentally, I don't like this approach. What does it matter whether the function is being inlined recursively or whether we're examining a 1000-function deep chain where each fn allocates a huge amount of stack space?
> 

The user determines the allocated stack space of a long chain of functions.  This is not the same as inlining a leaf function into a recursive function, which will make each step in the recursion allocate lots of memory. 

Note that the callee may be a library call, and the user may be surprised to see that their innocent looking recursive caller code crass due to stack overflow. 

> We should either have a cut-off for "bytes of stack allocated that we can't reclaim by stack slot coloring", or else there should be a penalty for stack allocations (maybe starting above a given size) that can't be optimized away. Recursiveness doesn't enter into it.
> 
> If you think I'm mistaken and that recuriveness is a special case, then as a thought puzzle,

I think that recursive callers are special.  

> consider what it means when the function is recursive but passes entirely different arguments to itself.

The recursiveness detection code currently only checks for 1st level recursions. It does not catch A calls B that calls A. 

> Do you have any interest in analyzing the callee to see if it's a leaf-node in the recursion, based on the parameters being passed at the call-site? Is this at all different from calling an entirely different function?
> 

I am not sure I understand. The recursion usually calls itself with a different set of parameters, like N-1.   

In theory, I would like to check if all of the users of the allocas die due to the inlining and optimization of the callee.  In practice, I don't think that there are that many examples of recursive functions that call inline-able functions that allocate lots of stack space. 

Thanks,
Nadav