<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 9:04 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank" class="cremed">hfinkel@anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> The best approach that I have found is:<br>
> * Implement a general heap-to-stack optimization for LLVM<br>
<br>
</div>I'm completely on-board with this.<br></blockquote><div><br></div><div>It's not trivial to implement though, and even if we implement it (and I do want one!)...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
> * Add metadata on a call that LLVM recognizes as an allocation<br>
> function (eg, _Znwm or malloc) that says "try to promote this to the<br>
> stack, even if the allocation size is not constant"<br>
<br>
</div>This seems like a simple addition to the first option, allowing the user to override the cost model, right? I imagine that we might want to keep the malloc calls if the cost of the code in between the malloc and free is high (on the assumption that it is better not to unnecessarily increase register pressure by introducing dynamic allocations). This metadata would just tell the optimizer to do the transformation whenever legal. Is that the idea?</blockquote>
</div><br>But I'm really unsure when (if ever) we will *actually* want to move to the stack.... It blocks inlining, increases register pressure, etc... I just don't see a real demand for it.</div></div>