<div dir="ltr">All,<div><br></div><div>Just on the off chance people were curious: when I picked up Nick's change I had some (mostly aesthetic) issues with using std::sort and std::binary_search for this CL, but went ahead.  When someone asked me off-line mail why I was using WeakVH when my changes were entirely within an optimization pass, I hit the tipping point, and decided to take the step back and try using DenseSet, etc.  I didn't want the community wasting any more time reviewing the patch.  So I am making it waste time reading my missives instead.  :-)  Thanks for your patience.</div>
<div><br></div><div>David</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 3:22 PM, David Sehr <span dir="ltr"><<a href="mailto:sehr@google.com" target="_blank">sehr@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Please ignore this patch for now.  I am revising it according to some input provided off-line.<span class="HOEnZb"><font color="#888888"><div>
<br></div><div>David</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 8:59 AM, David Sehr <span dir="ltr"><<a href="mailto:sehr@google.com" target="_blank">sehr@google.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Duncan,<div><br></div><div>Yes, my comments were a bit terse, to be sure.  Nick's patch enables tail call elimination (including tail recursion elimination) subject to two constraints on the function F being transformed:</div>


<div>1) alloca addresses cannot be *captured* by any call site in F.</div><div>2) alloca addresses cannot be *used* by the candidate call site S for tail call elimination.</div><div><br></div><div>
There was a small bug in how condition (2) was enforced.  It was only being enforced for tail calls to functions other than F (recursive calls).  My change checks the use of alloca both for labeling call sites with "tail" and when converting them to iteration.</div>

<span><font color="#888888">
<div><br></div><div>David</div></font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 6:12 AM, Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<div><div><br>
<br>
On 10/02/13 23:50, David Sehr wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch enables tail call optimization when alloca instructions are present.<br>
  It is based on<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/153958.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvm-commits/Week-<u></u>of-Mon-20121022/153958.html</a>, by<br>
adding a check that alloca addresses are not used by tail recursion candidates.<br>
</blockquote>
<br></div></div>
did you change something wrt Nick's patch?<br>
<br>
Ciao, Duncan.<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>