[PATCH] Move ownership of GCStrategy objects to LLVMContext

[Chandler Carruth]

On Tue, Jan 13, 2015 at 5:58 PM, Philip Reames <listmail at philipreames.com>
wrote:

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

This will break builds of folks that don't link CodeGen at all. Since
CodeGen depends on IR already, you can safely do a mechanical move from one
library to the other, and then do the refactorings you have in mind if that
makes things cleaner for you?


>
> Just to be clear, does anyone have concern about the *actual ownership*
> change?
>

I actually do have some concerns, but I don't really have any good answers
yet. Here is my current thinking, which I'm not confident in and may be
quite broken:

I feel like this isn't an IR construct so much as a utility for examining
or analyzing the IR construct, and the IR construct is just a function
attribute. Would it make sense to structure the code that way? I'm
imagining a GCStrategyAnalysis and MachineGCStrategyAnalysis or something
similar which can operate both at the IR level and at the MI level. But
I've not worked enough with GCStrategy to know whether this works, or if it
doesn't, why it doesn't and whether the problem is fundamental or fixable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150113/4b580296/attachment.html>