[PATCH] Move ownership of GCStrategy objects to LLVMContext
listmail at philipreames.com
Tue Jan 13 17:58:29 PST 2015
On 01/12/2015 11:33 PM, Chandler Carruth wrote:
> On Mon, Jan 12, 2015 at 11:18 PM, Nick Lewycky <nicholas at mxc.ca
> <mailto: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
> 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).
This is pretty much exactly what I have in mind. I had hoped that this
would be suitable as an intermediate step, it sounds like the answer is
no. I'll look at trying to pull GCStrategy further into IR to avoid the
lowering issue. If I can get the header across the line, do either of
you object if some of the *implementation* stays in CodeGen for the
moment? (As in, for a few days, until I can follow on changes in.) I'm
really trying to avoid one massive change that rips the entire thing
apart and puts it back together.
Just to be clear, does anyone have concern about the *actual ownership*
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits