<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 12, 2015 at 11:18 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Philip Reames wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi chandlerc, nicholas, sanjoy,<br>
<br>
(I would appreciate a close review on this one.  I'm changing ownership in a non-trivial way and am introducing what might be considered a layering violation - IR owrning and returning pointers to a CodeGen class.)<br>
</blockquote>
<br></span>
Sorry but that's a non-starter right there. We can't have IR depending on Codegen (unless you want to make Codegen not depend on IR).<br>
<br>
We can cheat a little; we could move GCStrategy.h into the IR and forward-declare MachineFunction and pass it by pointer to findCustomSafePoints.<br>
<br>
Should there be a split, GCStrategy (IR) and MachineGCStrategy? There isn't enough IR-side user of the new API for me to judge how to deal with it, even D6808 pretty much just uses isGCManagedPointer.</blockquote></div><br></div><div class="gmail_extra">Given the core description, it seems clear that the goal is for GCStrategy to be lifted up to the IR level, Context-owned, and looked up via a function attribute.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The question is how to deal with the MachineFunction. If it is intrinsically necessary to the functioning of these things, then yea, I think you'll need a split between GCStrategy and MachineGCStrategy that wraps it. If possible, you might be able to re-cast the entire GCStrategy API in terms of the IR-layer Function (and look up that function from the MachineFunction when in CodeGen).</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>