[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