<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 12, 2014 at 1:56 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tue, Feb 11, 2014 at 10:42 AM, Eli Bendersky <<a href="mailto:eliben@google.com">eliben@google.com</a>> wrote:<br>


</div><div class="">> 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 capabilities<br>
> may be useful to custom tools. However, as it stands now opt is now very<br>
> modular - almost all its functionality is contained within its main opt.cpp<br>
> 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 is<br>
> duplicated in llc.cpp; the same is true for the logic of adding optimization<br>
> passes between opt.cpp and Clang (a comment in opt.cpp even admits it<br>
> "duplicates llvm-gcc behaviour", showing its age :-) A lot of cl::opt<br>
> definitions are duplicated between different tools and have to be kept in<br>
> sync for consistency.<br>
<br>
</div>*nod*<br>
<div class=""><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 of<br>
> utility functions, as well as cl::opt definitions.<br>
><br>
> Such a transition can be done in steps: the first step would be to create<br>
> this OptTool within tools/opt. This would immediately enable building custom<br>
> opt-based tools by linking in the code from tools/opt, leaving<br>
> tools/opt/opt.cpp out. A more ambitious step would be to move the<br>
> functionality to a library (lib/Tools?) - enabling code reuse between<br>
> different LLVM tools as well as easier use within custom tools.<br>
><br>
<br>
</div>I'd prefer just going for the latter to minimize churn etc.<br>
Alternately we can leave it separated into tools/opt for now until we<br>
get the right interfaces. </blockquote><div><br></div><div>Yep, this is my main motivation to do it stepwise. The best interfaces may not be immediately obvious and polishing it within tools/opt in this case is the less-churn approach because once you go to a library and have a bunch of dependencies things are harder to change and test.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think the existing code has been around<br>
enough that moving it into a separate library will be fine.<br>
<div class=""><br>
> Any opinions / suggestions welcome. I'll be happy to send out piecemeal<br>
> patches that implement this refactoring.<br>
><br>
<br>
</div>I'll happily review.<br></blockquote><div><br></div><div>Thanks.</div><div><br></div><div>Eli</div><div> </div></div></div></div>