[PATCH] Move ownership of GCStrategy objects to LLVMContext

Chandler Carruth chandlerc at google.com
Mon Jan 12 23:33:32 PST 2015

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

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

More information about the llvm-commits mailing list