[llvm-dev] Preparing BOLT for LLVM monorepo

[Mehdi AMINI via llvm-dev]

On Mon, Dec 20, 2021 at 8:19 AM Rafael Auler <rafaelauler at fb.com> wrote:

> Hi Mehdi,
>
>
>
> You raise a good point. At the moment we reluctantly went with the clang
> dependency route for small tests and for more involved BOLT development we
> have an external binary repo that stores large pre-built applications to be
> used as tests. You are right with respect to the downsides, but the
> alternative, which is to depend on the host compiler (we were previously
> using host_cc in LIT for quite a while) can cause more headaches in terms
> of test stability because we don’t have control over which compiler was
> used to build LLVM. BOLT operates at level that changing even the linker
> can already introduce changes that may modify the outcome of a test.
>
>
>
> Regarding bugs in clang breaking BOLT tests, that is true. I wonder if
> this affects lldb a lot, though. It also depends on the trunk clang to
> build its tests. I imagine a debugger is also quite sensitive to the
> compiler used to build its test inputs.
>
>
>
> To summarize, I see 3 options here:
>
> 1 - depend on host compiler
>
> 2 - depend on trunk clang
>
> 3 - depend on pre-built binaries
>
>
>
> #1 is too unstable at the moment. It’s hard to communicate with other devs
> regarding why their test is failing because I can only repro it in my
> machine with my host compiler.
>
> #2 may be unstable because trunk clang can be broken, and new bugs may be
> introduced while clang is not fixed. In my experience, BOLT is not easily
> broken by LLVM code, though, so we can afford some time with the tests
> being offline.
>
> #3 is a burden on the repo because the pre-built binaries may occupy
> significantly more space than source code, and also are hard to read (even
> if using yaml).
>

Thanks for the explanations, it makes sense.
You may want to look at some point in the future into a CMake option for
folks to provide a pre-built clang/lld (we even have such an option for
providing a prebuilt TableGen when building LLVM).
That way one could invoke `cmake -DLLVM_ENABLE_PROJECTS=bolt
-DBOLT_CLANG_PATH=/toolchain/bin/clang -DBOLD_LLD_PATH=/toolchain/bin/lld`
I would expect that for day-to-day development on a non-very-powerful
machine that could make quite a difference for the casual developer.

Best,

-- 
Mehdi





>
>
> Best,
>
> Rafael
>
>
>
> *From: *Mehdi AMINI <joker.eph at gmail.com>
> *Date: *Friday, December 17, 2021 at 8:26 PM
> *To: *Rafael Auler <rafaelauler at fb.com>
> *Cc: *Hans Wennborg <hans at chromium.org>, Maksim Panchenko <maks at fb.com>,
> Xinliang David Li <xinliangli at gmail.com>, Fāng-ruì Sòng <
> maskray at google.com>, Sriraman Tallam <tmsriram at google.com>, Chris Lattner
> <clattner at llvm.org>, Andrey Bokhanko <andreybokhanko at gmail.com>,
> vladislav.khmelevskyi at huawei.com <vladislav.khmelevskyi at huawei.com>,
> tstellar at redhat.com <tstellar at redhat.com>, echristo at gmail.com <
> echristo at gmail.com>, Nick Desaulniers <ndesaulniers at google.com>,
> llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
> *Subject: *Re: Preparing BOLT for LLVM monorepo
>
> Hi,
>
>
>
> The instructions to build Bolt mention:
> -DLLVM_ENABLE_PROJECTS="clang;lld;bolt"
>
>
>
> It seems that clang is just a dependency here because you build C++
> sources during lit-tests execution, but it's not clear to me why we don't
> use the host compiler or a prebuilt release here? Is there an intrinsic
> coupling between clang and Bolt at HEAD?
>
>
>
> Having to build clang at HEAD just to run the bolt test seems like a
> non-trivial overhead for the casual developer, if the host compiler (or
> some clang pulled with apt-get or your favorite package manager) would just
> work.
>
> Also in CI, even if you have a beefy enough machine, you add risks for the
> Bolt bot to be broken because Clang/LLVM itself would be broken: so instead
> of tracking Bolt bugs you end up tracking clang issues. Also the fact that
> clang being broken implicating you can't test Bolt means that in the
> meantime new bugs can land in Bolt and complicate auto-bisection.
>
> (The same question applies to lld I think?)
>
>
>
> Thanks!
>
>
>
> --
>
> Mehdi
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Dec 7, 2021 at 5:36 PM Rafael Auler <rafaelauler at fb.com> wrote:
>
> Hi folks,
>
>
>
> https://github.com/facebookincubator/BOLT branch “main” contains a merge
> proposal of BOLT into llvm-project. This is llvm from Nov 30th with 1016
> commits on top of it corresponding to the BOLT project.
>
> These 1016 commits would ideally be committed in a merge commit, merging
> LLVM as the first parent and BOLT as the second, and would be there only
> for the purposes of preserving project history. In this way, they should be
> easily skippable during a bisect of LLVM in the same way as the merge
> commit of flang. These commits represent the linear history of BOLT on top
> of rebased LLVM, so most commits are not buildable (since we can’t build a
> very old version of BOLT on top of a recent LLVM base). That’s why this is
> for history/blame only.
>
>
>
> We have addressed the issues in
> https://github.com/facebookincubator/BOLT/issues/248 and we are happy to
> continue working on any extra suggestions.
>
> Would it be better if we put this branch as a PR into llvm-project as a
> way to make it easier for people to review it? I don’t think we can put
> this into phabricator. However, I guess github’s bot will probably
> auto-close the PR. Also feel free to open new issues against our
> facebookincubator/BOLT project as a way to review it.
>
> Thanks
>
>
>
> *From: *Hans Wennborg <hans at chromium.org>
> *Date: *Thursday, November 4, 2021 at 5:42 AM
> *To: *Maksim Panchenko <maks at fb.com>
> *Cc: *Xinliang David Li <xinliangli at gmail.com>, Fāng-ruì Sòng <
> maskray at google.com>, Sriraman Tallam <tmsriram at google.com>, Chris Lattner
> <clattner at llvm.org>, Andrey Bokhanko <andreybokhanko at gmail.com>, Rafael
> Auler <rafaelauler at fb.com>, vladislav.khmelevskyi at huawei.com <
> vladislav.khmelevskyi at huawei.com>, tstellar at redhat.com <
> tstellar at redhat.com>, joker.eph at gmail.com <joker.eph at gmail.com>,
> echristo at gmail.com <echristo at gmail.com>, Nick Desaulniers <
> ndesaulniers at google.com>, llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org
> >
> *Subject: *Re: Preparing BOLT for LLVM monorepo
>
> Hi Maksim,
>
> On Tue, Nov 2, 2021 at 9:52 PM Maksim Panchenko <maks at fb.com> wrote:
> > We are still working on finalizing the exact logistics of the merge.
> >
> > However, we expect to follow the Flang project's footsteps and run the
> >
> > "--no-ff" merge to preserve the history of ~1K commits. We would like to
> >
> > ask for help and coordination from the release managers Tom Stellard and
> >
> > Hans Wennborg.
>
> I'm no longer involved in release management, and don't really have
> any opinion on how to merge this.
>
> Thanks,
> Hans
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211220/520492a5/attachment-0001.html>