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

[Eli Bendersky]

On Thu, Feb 13, 2014 at 3:51 PM, Sean Silva <silvas at purdue.edu> wrote:

> I thought that opt was supposed to basically be a way to run a PassManager
> over some IR?
>

See some of my patches over the past week or so. opt has grown quite a bit
of functionality, some of which gets duplicated in other tools simply
because tools/opt/opt.cpp can't just be added to other tools.


> Seems like the new PM should standardize the appropriate things and have
> them be a natural part of its API.
>

I don't intend to modify anything about how the PM works, so ISTM these
changes are orthogonal. All I'm doing is encapsulating functionality from
the main opt.cpp file into self-contained utility modules that can also be
linked into other tools (existing and custom), avoiding code duplication.

Eli



>
> -- Sean Silva
>
>
> On Tue, Feb 11, 2014 at 1:42 PM, 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140213/d71b408a/attachment.html>