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

[Greg Fitzgerald]

+1.  With this change, the llvm build wouldn't need to optionally
reference polly.  Instead, the polly build could create a one-off
version of opt that includes the static-linked polly library (perhaps
named spopt?).  The polly build would use that executable instead of
opt for its unit tests.

>From a package management perspective, llvm would be a standalone
package, polly would depend on it, and clang would depend on both
polly and llvm.  Good stuff.

-Greg



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.
>
> 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.
>
> Any opinions / suggestions welcome. I'll be happy to send out piecemeal
> patches that implement this refactoring.
>
> Eli
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>