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

[Pete Cooper]

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.

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.

Thanks,
Pete
> On Mar 4, 2015, at 1:23 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> Hi dblaikie,
> 
> This will provide the analogous replacements for the PassManagerBuilder
> and other code long term. This code is extracted from the opt tool
> currently, and I plan to extend it as I build up support for using the
> new pass manager in Clang and other places.
> 
> Mailing this out for review in part to let folks comment on the terrible names
> here. A brief word about why I chose the names I did.
> 
> The library is called "Passes" to try and make it clear that it is a high-level
> utility and where *all* of the passes come together and are registered in
> a common library. I didn't want it to be *limited* to a registry though, the
> registry is just one component.
> 
> The class is a "PassBuilder" but this name I'm less happy with. It doesn't
> build passes in any traditional sense and isn't a Builder-style API at all. The
> class is a PassRegisterer or PassAdder, but neither of those really make a lot
> of sense. This class is responsible for constructing passes for registry in an
> analysis manager or for population of a pass pipeline. If anyone has a better
> name, I would love to hear it. The other candidate I looked at was
> PassRegistrar, but that doesn't really fit either. There is no register of all
> the passes in use, and so I think continuing the "registry" analog outside of
> the registry of pass *names* and *types* is a mistake. The objects themselves
> are just objects with the new pass manager.
> 
> http://reviews.llvm.org/D8054
> 
> Files:
>  include/llvm/Passes/PassBuilder.h
>  lib/CMakeLists.txt
>  lib/LLVMBuild.txt
>  lib/Makefile
>  lib/Passes/CMakeLists.txt
>  lib/Passes/LLVMBuild.txt
>  lib/Passes/Makefile
>  lib/Passes/PassBuilder.cpp
>  lib/Passes/PassRegistry.def
>  tools/opt/CMakeLists.txt
>  tools/opt/LLVMBuild.txt
>  tools/opt/NewPMDriver.cpp
>  tools/opt/PassRegistry.def
>  tools/opt/Passes.cpp
>  tools/opt/Passes.h
> 
> EMAIL PREFERENCES
>  http://reviews.llvm.org/settings/panel/emailpreferences/
> <D8054.21177.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

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