[PATCH] [PM] Create a separate library for high-level pass management code.

[Pete Cooper]

> On Mar 5, 2015, at 1:58 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
> 
> On Thu, Mar 5, 2015 at 10:21 AM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote:
> Hi Chandler
> 
> Sorry to chime in late on this one.
> 
> Recently Chris suggested a new library for ‘ToolsSupport’ which would pull some stuff out of libSupport which isn’t needed by all tools.  
> 
> Your response <http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-November/078624.html> to this was 'The reason isn't fundamental, it's just that splitting libraries, especially as LLVM is currently set up, has a cost. Super fine-grained libraries don't really make sense in this environment’
> 
> I’d like to understand where you’re going with libPasses as this initial patch definitely fits the category of being fine-grained.  Now if this is going to grow in to a library with (and i’m picking a purely arbitrary number here) say 10 files, then sure it might be worth it.  If its going to be 2 or 3 files then i’d say it too fine grained.
> 
> Ah, yes, this needs a bit more context.
> 
> The key is that splitting out CrashRecovery wasn't really necessary. libSupport is an "ok" place to put it, if maybe not ideal. So when we look at splitting it out, the somewhat mundane costs associated in LLVM-land make it questionable IMO.
> 
> Here we have a slightly different situation. We don't actually have a library which is layered here: depending on transforms, analyses, and targets. So in this case I think we need a separate library for a fundamental reason, not a convenience. As such, even though it costs some, I think it's the right thing to do.
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.

Then the question becomes:
- Is that gross putting the pass manager in there?
- Will there come a time when you actually want passes and don’t have IR?

I think if the answer to either of those questions is ‘yes’, then go for it.  Otherwise i’m not opposed to the library (i.e., go for it if no-one else is strongly opposed), but i’m also not seeing a big win either.

Thanks,
Pete
> 
> Given that, I'd rather at least start off with a narrow and focused scope for the library. While it might not hit 10 files, I think long term there will be a reasonable amount of code here. For example, all of the textual pass pipeline parsing and analysis registration is mechanically expanded, but of a reasonable size. I'm hoping to keep it to 3 to 5 files, but those may grow to be reasonably complex.
> 
> If it turns out we actually have other less related stuff that also fits at this layering level, it might make sense to make this a more generic library and merge them because of the overhead.
> 
> Does that make sense to you?
>  
> 
> But saying that, I actually would love to see LLVM being *much* more modular than it currently is.  I don’t have a use case where i’d ever not link libPasses, but i’d welcome an effort to split out some other libraries where it makes sense.  I’m not necessarily talking about libToolsSupport here, just a general comment about the size of some libraries, especially the amount of stuff which is piling up in libSupport.
> 
> Yea, I don't fundamentally disagree. There are a lot of challenges of getting to that point, especially around build systems and managing library dependencies, but I agree it would be an abstractly better place to be.  Hopefully the fundamental need is worth the cost in the interim, and maybe we'll have a better story for managing dependencies and library boundaries in the future.

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