[LLVMdev] Proposal: split tools/opt/opt.cpp to OptTool and a smaller main()

[Eli Bendersky]

On Wed, Feb 12, 2014 at 1:56 PM, Eric Christopher <echristo at gmail.com>wrote:

> On Tue, Feb 11, 2014 at 10:42 AM, Eli Bendersky <eliben at google.com> wrote:
> > Hello,
> >
> > I started some refactoring work on tools/opt/opt.cpp in r201116, but
> > conceptually this is part of a larger effort. I'd like to consult with
> > llvmdev@ about the best way to move this forward.
> >
> > Background: opt is a very useful swiss-army-knife tool, and its
> capabilities
> > may be useful to custom tools. However, as it stands now opt is now very
> > modular - almost all its functionality is contained within its main
> opt.cpp
> > file.
> >
> > I think this is also the cause of some code duplication that currently
> > exists between different LLVM tools. For example, some code from opt.cpp
> is
> > duplicated in llc.cpp; the same is true for the logic of adding
> optimization
> > passes between opt.cpp and Clang (a comment in opt.cpp even admits it
> > "duplicates llvm-gcc behaviour", showing its age :-) A lot of cl::opt
> > definitions are duplicated between different tools and have to be kept in
> > sync for consistency.
>
> *nod*
>
> >
> > What I'd like to see is most of opt's functionality moving outside of
> > opt.cpp to make it reusable in other tools. For example, this could be
> > encapsulated in a class named OptTool, or just a namespace with a bunch
> of
> > utility functions, as well as cl::opt definitions.
> >
> > Such a transition can be done in steps: the first step would be to create
> > this OptTool within tools/opt. This would immediately enable building
> custom
> > opt-based tools by linking in the code from tools/opt, leaving
> > tools/opt/opt.cpp out. A more ambitious step would be to move the
> > functionality to a library (lib/Tools?) - enabling code reuse between
> > different LLVM tools as well as easier use within custom tools.
> >
>
> I'd prefer just going for the latter to minimize churn etc.
> Alternately we can leave it separated into tools/opt for now until we
> get the right interfaces.


Yep, this is my main motivation to do it stepwise. The best interfaces may
not be immediately obvious and polishing it within tools/opt in this case
is the less-churn approach because once you go to a library and have a
bunch of dependencies things are harder to change and test.



> I think the existing code has been around
> enough that moving it into a separate library will be fine.
>
> > Any opinions / suggestions welcome. I'll be happy to send out piecemeal
> > patches that implement this refactoring.
> >
>
> I'll happily review.
>

Thanks.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140212/cd876835/attachment.html>