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

[Eli Bendersky]

On Thu, Feb 13, 2014 at 9:56 PM, Nick Lewycky <nicholas at mxc.ca> wrote:

> What exactly do you have in mind? The reusable part of what opt does is
> already factored into the pass manager builder. Everything else is file
> I/O, debugging, or flags management.
>
> Put another way, opt is a collection of all the boiler plate you could
> ever want to use, but that's not a good line to refactor along. Having all
> this stuff -- let's take the flags as one example -- is sensible for opt
> because it's an internally facing tool for compiler developers, but it's
> not a reusable part.
>

This email outlined the general approach, but the more concrete steps are
best viewed through the patches I was sending this week. Yes, opt is a
collection of a lot of boilerplate and yes, some of it really does belong
in the main opt.cpp file; but some other parts could be separated into
standalone modules (starting with h/cpp pairs in tools/opt and maybe at
some point moving to a library if that starts making sense).

The benefits are twofold. One is removing code duplication within existing
LLVM tools:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140210/204847.htmlis
a good example.

Another is enabling opt-like tools to be written without duplicating a lot
of opt. Today, if I want to write a custom tool based on LLVM libraries
that runs some custom passes as well as adding LLVM optimization passes,
ISTM I have to copy-paste a lot of code from opt.cpp; my goal is to reduce
this amount - not to zero, which isn't realistic, but to at least reduce
it. When all of my patches are augmented in my local branches, the size of
opt.cpp already goes down from ~900 LOC to half that size, and much of the
remnants are irreducible like flags and main() logic.

Eli




>
> Eli Bendersky 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140214/d6918a96/attachment.html>