This is an archive of the discontinued LLVM Phabricator instance.

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

Authored by chandlerc on Mar 4 2015, 1:23 AM.

Details

Summary

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.

Diff Detail

Repository
rL LLVM

Event Timeline

chandlerc updated this revision to Diff 21177.Mar 4 2015, 1:23 AM
chandlerc retitled this revision from to [PM] Create a separate library for high-level pass management code..
chandlerc updated this object.
chandlerc edited the test plan for this revision. (Show Details)
chandlerc added a reviewer: dblaikie.
chandlerc added a subscriber: Unknown Object (MLST).
hfinkel added a subscriber: hfinkel.Mar 4 2015, 8:01 AM

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.

A little verbose, but how about something like PassPipelineBuilder?

pete added a subscriber: pete.Mar 5 2015, 10:21 AM

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

This revision was automatically updated to reflect the committed changes.
llvm/trunk/tools/opt/PassRegistry.def