<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 12:56 AM, Nick Lewycky <span dir="ltr"><<a href="mailto:nicholas@mxc.ca" target="_blank">nicholas@mxc.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>

<br>
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.</blockquote><div><br></div><div>This is a great way to put it.</div><div><br></div>
<div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<br>

<br>
Eli Bendersky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hello,<br>
<br>
I started some refactoring work on tools/opt/opt.cpp in r201116, but<br>
conceptually this is part of a larger effort. I'd like to consult with<br>
llvmdev@ about the best way to move this forward.<br>
<br>
Background: opt is a very useful swiss-army-knife tool, and its<br>
capabilities may be useful to custom tools. However, as it stands now<br>
opt is now very modular - almost all its functionality is contained<br>
within its main opt.cpp file.<br>
<br>
I think this is also the cause of some code duplication that currently<br>
exists between different LLVM tools. For example, some code from opt.cpp<br>
is duplicated in llc.cpp; the same is true for the logic of adding<br>
optimization passes between opt.cpp and Clang (a comment in opt.cpp even<br>
admits it "duplicates llvm-gcc behaviour", showing its age :-) A lot of<br>
cl::opt definitions are duplicated between different tools and have to<br>
be kept in sync for consistency.<br>
<br>
What I'd like to see is most of opt's functionality moving outside of<br>
opt.cpp to make it reusable in other tools. For example, this could be<br>
encapsulated in a class named OptTool, or just a namespace with a bunch<br>
of utility functions, as well as cl::opt definitions.<br>
<br>
Such a transition can be done in steps: the first step would be to<br>
create this OptTool within tools/opt. This would immediately enable<br>
building custom opt-based tools by linking in the code from tools/opt,<br>
leaving tools/opt/opt.cpp out. A more ambitious step would be to move<br>
the functionality to a library (lib/Tools?) - enabling code reuse<br>
between different LLVM tools as well as easier use within custom tools.<br>
<br>
Any opinions / suggestions welcome. I'll be happy to send out piecemeal<br>
patches that implement this refactoring.<br>
<br>
Eli<br>
<br>
<br>
<br></div></div><div class="">
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>