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

Hal Finkel hfinkel at anl.gov
Sun Sep 16 06:20:09 PDT 2012


On Sun, 16 Sep 2012 15:58:10 +0300
Nadav Rotem <nrotem at apple.com> wrote:

> Hi Hal, 
> 
> Because TargetData may not always be available. If TD is unavailable
> we have no way of knowing the size of arrays of pointers. 

True, but if that's the case, then make a conservative guess (say 64
bits), or don't perform the check at all. I would not otherwise base any
design decisions on the possible lack of TargetData.

 -Hal

> 
> Thanks
> 
> On Sep 16, 2012, at 3:44 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > Nadav,
> > 
> >> +// Do not inline array allocas with more than this many intems
> >> into recursive +// function calls.
> >> +const int RecursiveArrayAllocThreshold = 128;
> > 
> > Why is this in items and not in bytes?
> > 
> > -Hal
> > 
> > On Sun, 16 Sep 2012 15:16:43 +0300
> > Nadav Rotem <nrotem at apple.com> wrote:
> > 
> >> Hi, 
> >> 
> >> I am looking at a test case that looks like this:
> >> 
> >> void foo() {
> >>  ... foo();   // I'm recursive!
> >> 
> >>   bar();
> >> }
> >> 
> >> bar() {  int a[1000];  // large stack size }
> >> 
> >> If we decide to inline bar() into foo()  we may increase the stack
> >> size to the point of overflow.   I attached a patch to prevent
> >> inlining of callees which allocate large arrays into a recursive
> >> caller. 
> >> 
> >> Thanks,
> >> Nadav 
> >> 
> >> 
> >> 
> > 
> > 
> > 
> > -- 
> > Hal Finkel
> > Postdoctoral Appointee
> > Leadership Computing Facility
> > Argonne National Laboratory
> 



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list