<div dir="ltr">Ok, thanks. I'll go ahead and commit as is then.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 5, 2015 at 8:37 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On 2015-Dec-05, at 13:38, Keno Fischer <<a href="mailto:kfischer@college.harvard.edu">kfischer@college.harvard.edu</a>> wrote:<br>
><br>
> loladiro added a comment.<br>
><br>
> I would appreciate some guidance on how to go forward here. Walking and caching the intermediate chains doesn't make this significantly simpler, so the primary questions is whether the caching is worth it at all. Unfortunately, I don't have any large enough test cases with meaningfully nested inlining structures to be able to make such measurements here.<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D14697" rel="noreferrer" target="_blank">http://reviews.llvm.org/D14697</a><br>
<br>
</div></div>It looks like you're not really changing the algorithm, just fixing a<br>
bug where the SP could be missed.  In that case, this patch LGTM (as<br>
it is); it is clearly making things better.<br>
<br>
Changing the algorithm in the future to do some extra caching (or no<br>
caching) might be a good idea, but that seems independent.</blockquote></div><br></div>