<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 12, 2021 at 11:57 AM Rafael Auler <<a href="mailto:rafaelauler@fb.com">rafaelauler@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_7578992296032761995WordSection1">
<p class="MsoNormal">Chris, the approach of living under /bolt sounds reasonable to me.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mehdi and David, the difference of doing things in-tree vs out-of-tree is that, currently, BOLT out-of-tree has
<u></u><u></u></p>
<p class="MsoNormal">  (1) different legal requirements for accepting contributions (external contributions require devs to sign a CLA). So I agree with Mehdi that the same forks will get broken as we refactor code, but once BOLT is in the llvm monorepo, at
 least they will have the chance to upstream it with different legal requirements. If they don’t want to upstream it, that’s fine too, but I would like to give them a chance.<br>
  (2) a different development workflow that is less open than LLVM’s. Because we want the input of the community on a refactoring that reflects how they want to use the libraries too, it would be more natural for this to happen inside in-tree LLVM.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">David, if we try to coordinate this refactoring happening in both repos (library part in LLVM while the client part in our separate repo), that will be challenging to do because we wouldn’t be able to easily test the LLVM’s diffs – a problem
 we are already facing with upstreaming our changes to LLVM without BOLT being there to easily show devs how our changes are actually used and tested. Moreover, other contributors who don’t have easy access to our github repo will have a hard time working with
 us in the refactor as they wouldn’t be able to do work on the tool (just the open library).</p></div></div></blockquote><div><br></div><div>Hi Rafael, I am not actually proposing an intermediate state where parts of BOLT lives in LLVM while the client lives in a separate repo. What I meant is a restructuring step within BOLT before dropping in LLVM.  For instance, in the bolt's top directory, there are lots of different things -- different driver programs, profile reader/writers, debug info handling, exception handling code, BOLT IR/core data structures (BB, Loop, Function) etc, pass managers etc. The Pass directory is also pretty flat.   Some preliminary reorganization with more tests added can reduce a lot of churns in the future. WDYT?</div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_7578992296032761995WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Mehdi, your suggestion looks good, I intend to show everyone the monorepo snapshot. We are making sure it is ready to be published and that’s why I’ve been referring to our snapshot as “imagine our github repo contents are under /bolt”
 because that is pretty much it, but I will present it soon.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">Xinliang David Li <<a href="mailto:xinliangli@gmail.com" target="_blank">xinliangli@gmail.com</a>><br>
<b>Date: </b>Thursday, March 11, 2021 at 11:33 PM<br>
<b>To: </b>Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>><br>
<b>Cc: </b>Rafael Auler <<a href="mailto:rafaelauler@fb.com" target="_blank">rafaelauler@fb.com</a>>, llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, Andrey Bokhanko <<a href="mailto:andreybokhanko@gmail.com" target="_blank">andreybokhanko@gmail.com</a>><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] BOLT: A Framework for Binary Analysis, Transformation, and Optimization<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal">Dropping Bolt to the top level directory sounds reasonable, but perhaps a hybrid approach similar to what is mentioned by Medhi can be applied. Basically Bolt first goes through a round of refactoring in github upstream first with design
 that is close to the future structure in LLVM, and then drops in as a monolithic piece initially. This will make future restructuring much easier. There are other benefits: 1) it is a good opportunity to clean up Bolt's internal APIs 2) It is time to beef
 up unittests;  3) it makes code review easier.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">David<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Mar 11, 2021 at 10:34 PM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">On Mar 11, 2021, at 9:40 PM, Rafael Auler via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">Hi Mehdi and David,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Indeed, we share similar concerns. We do intend to move functionality of BOLT to live as a library, but the timeline is unclear. In fact, most of BOLT could live in a library already, it’s just a matter of moving some files into separate
 components. Instead of the files living in tools/llvm-bolt, most could just be moved under lib/something, and we already have a llvm-bolt.cpp file that instantiates the driver that coordinates the binary rewriting process, which is the entry point of BOLT
 as a library. People could already leverage this to use BOLT in different ways (for example, I wrote some time ago a different utility that runs the driver for two different binaries and compares the two – this was named boltdiff later).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">My main reason for committing the project as a whole first, in the same way as flang did, though, (as a project merged into the monorepo), is because BOLT is already opensource for a while, and it is a 6-year old project with about 800
 commits and 50K lines of code and we know we have people who forked the project and would like to contribute to it. If I commit into LLVM a different BOLT (not just rebased), then I (a) break or make it hard for any work on top of it from other contributors,
 (b) lose the original history or make it harder to preserve it.  That’s why I was going for a more smoother transition. I, as a developer, put value in the ability to blame and to understand why things were built a certain way, and not bringing BOLT’s history
 (in the same way as flang did) would mean we and the community loses a lot of context on the decisions of the project. And I guess that’s also the rationale for a monorepo, to have multiple projects merged together.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Because of that, I initially put bolt under /bolt, following flang’s model of merging the history so every developer has the right context. But the original location was under llvm/tools.<u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As with others, I’m not very aware of the internal architecture of bolt, so take this with a grain of salt:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">From what I understand, I have a slight preference for starting this out as a /bolt top level “subproject”, because the code currently sounds monolithic.  As the implementation logic is refactored into more reusable units, those library
 can be cleanly movable within the monorepo, e.g. under the llvm-project/llvm directory if appropriate.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The advantage of doing this is that nothing in the llvm-project/llvm repo can come to depend on the bolt code until and if it gets refactored.  This is also how things like LLDB started out (and it would be great for more of the reusable
 libraries in LLDB to be merged into LLVM over time).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Does anyone have any concerns about this approach?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Unrelatedly, I’d also love to see the llvm repository exploded a bit into more top level repos, e.g. splitting support/adt out to their own thing.  It is also worth considering splitting the MC layer out to its own thing as well, LLVM IR
 and the mid-level optimizer into its own thing, and CodeGen and the targets into its own thing.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The major constraint we need is that we want the dependences between top-level subproject to be a strong DAG between the subproject now and defensible into the future, and we don’t want minor evolution of the codebase to cause libraries
 to have to be moved around.  The benefit of splitting it up is easier to enforce layering, encouraging LLVM developers to work across subproject a bit more, and making it easier for subproject to depend on slices of “the big llvm directory”.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">-Chris<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>

</blockquote></div></div>