[PATCH] Move ownership of GCStrategy objects to LLVMContext

[Chandler Carruth]

On Mon, Jan 12, 2015 at 11:18 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

> Philip Reames wrote:
>
>> Hi chandlerc, nicholas, sanjoy,
>>
>> (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.)
>>
>
> 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).
>
> We can cheat a little; we could move GCStrategy.h into the IR and
> forward-declare MachineFunction and pass it by pointer to
> findCustomSafePoints.
>
> 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.


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.

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).

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150112/ee25e05f/attachment.html>