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

[Patrik Hägglund H]

+1

To make opt+llc more aligned with the clang driver would be very helpful!

/Patrik Hägglund

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Bendersky
Sent: den 11 februari 2014 19:42
To: LLVM Developers Mailing List
Subject: [LLVMdev] Proposal: split tools/opt/opt.cpp to OptTool and a smaller main()

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

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