[llvm-commits] [PATCH] A fix for the inliner heuristics for recessive calls

[Nadav Rotem]

On Sep 16, 2012, at 10:14 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> I also agree with Hal that we need to use target data when we have it to make this call. I think the inline cost already deals with this, but I'd have to look at the code.
> 

Done. 

> My other concern is that I think this is way too aggressive. The mere presence of such an alloca shouldn't disable inlining. Consider these scenarios:
> - What if inlining is the thing that allows the array to be broken up by SROA, and most of the dead sections removed?
> - What if after inlining all uses of the array are deleted as dead code?
> - What if after inlining 'foo' is no longer recursive?
> 
> I think by doing a much more detailed analysis within the inline cost framework (which already does per-instruction analysis) can solve at least the first two issues by making the logic be to not inline if:

I re-implemented it inside CallAnalyzer. 

> 1) We have an alloca with a static size greater than X, and
> 2) It is escaped (for the purposes of SROA) along the conservatively live code path
> I think you can assume that if SROA will fire for the alloca after inlining (likely due to only a subset of the function being live), the inlining is fine. The instruction threshold should bound the amount of post-split stack space growth.
> 
> I don't have any ideas about how to catch the third problem above, but that one seems the least likely to be a problem in practice.


I implemented the revised patch as part of the CallAnalyzer. The alloca-visitor collects the size of the statically allocated memory and we abort the inlining once we pass a threshold.  SROA is less of an issue because we only consider arrays, and the threshold is really high.

Attached a revised patch. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recursive_inline.diff
Type: application/octet-stream
Size: 8580 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120918/765de893/attachment.obj>
-------------- next part --------------


Thanks,
Nadav