[PATCH] [PM] Create a separate library for high-level pass management code.
peter_cooper at apple.com
Thu Mar 5 15:00:02 PST 2015
> On Mar 5, 2015, at 2:56 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Mar 5, 2015 at 2:51 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
>> On Mar 5, 2015, at 2:47 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>> On Thu, Mar 5, 2015 at 2:46 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
>> Yeah, I agree that layering is an issue.
>> The current pass code is in lib/IR, which I think is libCore. There’s no fundamental reason why your code couldn’t also live there right now. Its linked against everything you mentioned already.
>> Wait, you've lost me.
> I’m talking about what if you didn’t create a new library. I think you’re talking about the relationship between the new libPasses and other libraries. Otherwise i’m lost too :)
> I was saying that if you didn’t create a new library, then I assumed the new PM code could live in libCore next to the current PM code. And then everything just depends on libCore as they currently do.
> No no, that's the problem. Everything depends on libCore. Including libTransforms, libTarget, etc.
> the code i've got in Passes right now depends on code in the target library and in the transforms and analysis library. It can't do that from libCore without creating a cycle.
Ah, i see. Ouch!
> So we have:
> parsePassPipeline -> SROA (libTransforms) -> PassManager (IR / Core)
> If we put parsePassPipeline in Core, we form a cycle.
So how much of this is going to be optional? If I create a dylib, can I opt out of parsePassPipeline (export list probably), and therefore not have to link all the passes? I don’t want to have to carry around passes I know I don’t need.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits