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

[Nick Lewycky]

Patrik Hägglund H wrote:
> +1
>
> To make opt+llc more aligned with the clang driver would be very helpful!

I don't think that's one of the possible outcomes. Clang has its own 
flag processing, and llvm parts can not depend on clang parts so opt 
can't use clang's flag processing. Clang can't use llvm's flag 
processing either because llvm does keep a single global flag state, 
breaking the model of having clang linked into your program as a library 
and processing different files with different sets of flags.

Nick

>
> /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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev