<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 22, 2014 at 4:32 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does anyone have any high-level feedback on this idea? I think the code is in reasonable shape, and it would be good to get this in and iterate.</blockquote></div><br>Having discussed this really extensively with you, and read through the patch, I think this LGTM.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think further tweaks to this design can and should happen in post-commit review and follow-up patches. This is a reasonably invasive thing, so I think those will come, but I don't think we need to hold this up.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If anyone ever comes up with a fundamentally better way of modeling these concepts (accessing another function's allocations via its frame pointer) we can always rip this stuff out. It isn't *that* invasive.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I do continue to dislike the names, but I don't have good ideas for better. My complaints about the names are:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) We need to make up our mind about foo_bar vs. foobar. But llvm.frameaddress makes me not want to change course here.</div><div class="gmail_extra">2) "recoverframeallocation" is the name that just seems *weird* to me. would just "frameallocation" be better? Unsure.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We can tweak the names right up until 3.6 branches though, so I'm not really worried with checking this in using todays names until better ones occur to someone.</div></div>