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

[Sean Silva]

On Fri, Feb 14, 2014 at 12:56 AM, 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.


This is a great way to put it.

-- Sean Silva


> 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.
>
> 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
>>
>
> _______________________________________________
> 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/20140215/1045c30b/attachment.html>