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

[Chandler Carruth]

On Thu, Mar 5, 2015 at 10:21 AM, Pete Cooper <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.

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/ccb81164/attachment.html>