[llvm-dev] Best practices for rebasing nascent backend?

Brian Cain via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 12 19:27:20 PST 2021


If the "pre-merge checks" presentation from recent dev-meeting [1] is to be
believed, many revisions proposed for review fail build/tests.   But now
that we have those checks, hopefully John's experience for plucking an
arbitrary commit from main might give better results than in years past.

Another approach might be to review the buildbots to find a commit that is
green across the board.

[1] https://llvm.org/devmtg/2020-09/slides/Goncharov-Pre-merge_checks.pdf

On Fri, Mar 12, 2021 at 9:02 PM Neil Nelson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Not aware that main is broken in many of the test suites. It will be
> helpful to provide the bugs you find. Or if you can provide a command
> sequence I can do that here on Ubuntu.
>
> Perhaps if you give specific detail about the issues you are facing it
> will allow the other contributors to make suggestions.
>
> Neil Nelson
> On 3/12/21 4:50 PM, John Byrd via llvm-dev wrote:
>
> Dear llvm,
>
> A few of us are working on a novel LLVM backend in a separate repository,
> and our new branch uses a lot of the fancy new MLIR stuff.  We'd like the
> group's opinions as to best practices for keeping in sync with llvm's
> main branch.
>
> Some of us opine that we should be periodically rebasing our backend on
> the tip of main.  This has the advantage that we benefit from new main
> features, but it has the disadvantage that main seems to usually be broken
> in many of the test suites. So it's hard to find a stable commit in main,
> which passes all the tests on all the buildbots, that we can rebase onto.
>
> And some of us opine that we should be merging our work with main.  This
> has the advantage that we never rewrite history, but it also means that it
> will be painful to squash or rebase our commits, if we ever decide to
> submit our work upstream.
>
> We've considered doing our work based on one of the release branches, but
> until recently the development docs recommended against this.
>
> Wisdom would be appreciated; thank you.
>
> --
> ---
>
> John Byrd
> Gigantic Software
> 2321 E 4th Street
> Suite C #429
> Santa Ana, CA  92705-3862
> http://www.giganticsoftware.com
> T: (949) 892-3526 F: (206) 309-0850
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210312/a567873e/attachment.html>


More information about the llvm-dev mailing list