[llvm-dev] [RFC] BOLT: A Framework for Binary Analysis, Transformation, and Optimization

Tue Apr 13 14:12:20 PDT 2021

A quick update on the status of the BOLT proposal and migration to the monorepo:

We have finished an internal effort of migrating BOLT to the latest LLVM, and switching our current GitHub repo is the next intermediate step.

We appreciate everyone's comments and time spent reviewing the code.

In general, I agree with the sentiment expressed by David and others regarding the refactoring work. As always, the devil is in the details, and we need to establish a reasonable baseline for BOLT before it could be committed to the monorepo. We have already started working on fixing the concrete issues pointed by MaskRay, and more refactoring is underway. The testing is an important part of the migration as we are converting internal tests to public ones.

I like the idea of extracting the disassembler part of BOLT and making a serializable IR that could be reused by multiple tools/components.  The big question is whether we should include the serialization as part of the refactoring effort or not. IMHO it would be worth a separate RFC with the benefit of broader community input, and later we can switch BOLT to the newly developed low-level binary IR.

Maksim

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Fāng-ruì Sòng via llvm-dev <llvm-dev at lists.llvm.org>
Date: Thursday, March 18, 2021 at 12:07 PM
To: Andrey Bokhanko <andreybokhanko at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [RFC] BOLT: A Framework for Binary Analysis, Transformation, and Optimization
On Thu, Mar 18, 2021 at 9:26 AM Xinliang David Li via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> On Thu, Mar 18, 2021 at 1:48 AM Andrey Bokhanko <andreybokhanko at gmail.com> wrote:
>>
>> On Wed, Mar 17, 2021 at 10:54 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>> > Actually if I remember correctly flang went through multiple months of preparatory upgrade that were asked for by some people in the community, and they did so out-of-tree before getting ready to land in a single merge.
>>
>> I have to admit that contrary to OpenMP, that I followed very closely,
>> I only superficially followed flang development. Thus, I stand
>> corrected by Mehdi and Eric here.
>>
>> > We just have to make the expectation very clear and having a "moving goalposts" situation and it should work fine. Any particular reason that would put us in a "ad infinitum" situation?
>>
>> I said "we may end up" -- or we may not. :-) No particular reason
>> apart of history of software engineering. As you said, clear
>> expectations from the very start are a key ingredient to avoid this
>> happening.
>>
>> IMHO, it's infinitely better to start project development in a wide
>> and mature open source community ASAP -- at expense of some potential
>> refactoring work -- rather than delay until code is "good enough".
>> This says a man who spent most of his life working on proprietary
>> projects and used to argue with Chandler that "proprietary development
>> model is less expensive and leads to higher quality" (now I know
>> better). Just one man's opinion. It's fine to disagree.
>
>
> Not to disagree with what you said other than the 'infinitely' better part :) The situation here is different. BOLT has already gone through years of development so it is not really a new project to start with.
>
> Not saying it is actually the case, but it is very likely after years of fast pace development, there are lots of tech debts piled up for this project and it is now the *golden* opportunity to clean them up.  There will be way less momentum to do this kind of work after it gets in -- especially when there are other new dependencies start to get in the way.
>
> thanks,
>
> David
>
>>
>> Yours,
>> Andrey

Agree with others that some preparatory work needs to done first.
By exposing the project to a wider community it will get more readers
and offload some maintenance burden to the whole community.
There should be larger requirement on testing/documentation/tech debts
cleanup which could be of lower priority when it is developed in
house.
llvm-project probably does not lack development resources but the
review resource is definitely scarce in many areas.
The preparatory improvements can save all the reviewers from asking
some basics like coding standard suggestions (e.g.
https://github.com/facebookincubator/BOLT/issues/130)
and requesting better tests
(https://github.com/facebookincubator/BOLT/issues/129
https://github.com/facebookincubator/BOLT/issues/132 (split runtime
tests) https://github.com/facebookincubator/BOLT/issues/133
(Fine-grained tests)). I am concerned with the
completeness/robustness/conciseness of testsuite as well.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210413/7db8111a/attachment.html>