<div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 16, 2012 at 5:16 AM, Nadav Rotem <span dir="ltr"><<a href="mailto:nrotem@apple.com" target="_blank" class="cremed">nrotem@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am looking at a test case that looks like this:<br>
<br>
void foo() {<br>
  ... foo();   // I'm recursive!<br>
<br>
   bar();<br>
}<br>
<br>
bar() {  int a[1000];  // large stack size }<br>
<br>
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.<br></blockquote><div>
<br></div><div>I don't think this patch is the right way to solve the issue. This isn't an inliner issue, this is an inline cost issue, and I think you should sink the analysis to be part of the cost computation. For example, if someone marks 'bar' in your example as always-inline, they should get what they asked for.</div>
<div><br></div><div>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.</div><div><br></div><div>
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:</div><div>- What if inlining is the thing that allows the array to be broken up by SROA, and most of the dead sections removed?</div>
<div>- What if after inlining all uses of the array are deleted as dead code?</div><div>- What if after inlining 'foo' is no longer recursive?</div><div><br></div><div>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:</div>
<div>1) We have an alloca with a static size greater than X, and</div><div>2) It is escaped (for the purposes of SROA) along the conservatively live code path</div><div>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.</div>
<div><br></div><div>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.</div></div></div>