[RFC] Promoting the LoongArch backend from experimental to official

LLVM Project
1

Hi all,

Happy new year!

I would like to propose promoting the LoongArch backend from its current
experimental status to official before release/16.x branch is created.
This means that the LoongArch backend will be built by default and included in
standard binary distributions of LLVM/Clang.

Status

LoongArch is a RISC style ISA designed by Loongson Technology in China. It has
32- and 64-bit variants and it is composed of a basic part and four extensions.
Various products (e.g. laptops, desktops, workstations, servers) powered by
LoongArch are being sold on regular shops. A large number of basic software
communities including Linux, GCC, Binutils, Glibc and Golang have
released their versions support LoongArch.

A year ago, I sent a RFC proposing adding LoongArch backend to LLVM. Now I
think it is mature enough to be moved out of experimental. Some bases:

  • Small tests (e.g. .s, .ll, .mir, .c) were written when we submitted each
    non-NFC patch.
  • check-all and test-suite 100% pass without errors.
  • A buildbot was connected to the staging area. This bot builds
    (-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=LoongArch and
    -DLLVM_ENABLE_PROJECTS=clang) and tests check-all/test-suite
    with -j32 on a LoongArch machine natively. It has been green (except
    occasional broken builds caused by problematic patches) for more than 10
    days. There have been some pink mark failures caused by network
    connection problems. Now we have solved the network issues, and the bot
    become relatively stable.
  • LLVM/Clang-16 is able to build many large programs for LoongArch, e.g.
    Gcc, Binutils, Linux, Chromium, FFMpeg, SPECCPU, etc.
  • In addition to clang, a good part of others subprojects have been ported to
    LoongArch. For example, check-unwind and check-openmp 100% pass.
    Most components of compiler-rt are ready to use and more patches are
    under review (D140690, D140528, D139686, D140727). Basic functions of
    lldb are also avialable and a few more patches are under review (D140386,
    D140759, D140615). @xen0n has basically completed the lld support
    which is under review (D138135) and he plans to add extensive test coverage
    recently.

I believe that we are ready to flip the switch towards an official target. At
Loongson, we’re ready to address any issues that arise, and as noted below
we’re delighted that there’s a growing community of contributors around this
backend.

Thanks

I’d like to thank everyone who submitted reviews or patches, helped with setting
up buildbot. Beside the LLVM toolchain team at Loongson, there are many
names outside to mention. @rengolin, @xen0n, @MaskRay, @xry111,
@myhsu, @lrzlin, @gkistanova, @DavidSpickett, @prcups. I’m sorry if a name is missing.

End

Although becoming an official backend would be a huge milestone, of course it’s
far from the end of the road. We’ll be continuing to work on generated code
performance improvements, ISA extensions support, setting up more buildbots,
working with language communities like Rust, support for additional LLVM
features, etc.

What do you think? Any comments would be appreciated.

Regards,
Weining

2

Hi @SixWeining, what a great milestone! Thanks for your continued effort to add your target, following all the requirements and addressing every issue to date.

The LoongArch target seems to have covered all requirements from the policy, which is outstanding, but there are two small things that we may have to wait a bit more to flip the switch:

  1. The next stable branch is close, and from past experience, we need time to fix all the issues that becoming a default target brings. I propose we wait until the stable branch is fixed, and we work to have the next version (mid-23) as the first one with LoongArch built by default.
  2. A buildbot stable for 10 days is not long enough to claim stability. Previous experience has been that at least a couple of months is enough (easily done if we aim for the July release), because it takes weeks/months to trickle down to all downstream users.

Hopefully by then, both compiler-rt and lld support would be finished, and it will truly be a complete target.

3

Thanks for your comments @rengolin.

I just see this Upcoming release schedule? which means release/16.x would be branched on 4th Tue in January. We have ~3 weeks. And we may have another 2 weeks to cherry-pick bugfix patches before 16.0.0-rc2 is tagged. Is it enough? It will be a pity to LoongArch community if we can’t catch up with llvm16.

4

we need time to fix all the issues that becoming a default target brings

What sort of issues are you expecting to arise there? I would expect potentially some small number of compilation failures will pop up, due to exposure of the target-specific code to more of a diversity of compilers or compiler versions for the first time, and some small number simple test failures from running test cases on more OSes.

If the first attempt to enable the target is within the next few days, seems like there should be plenty of time to flush that sort of problem out?

5

Sometimes it takes weeks to reach some downstream code and then we need to patch the previous release if it’s too close to the branch.

But, I’m not strongly bound to the idea of waiting. If the consensus is that we can do it now, by all means, let’s do it now.

@SixWeining has already shown they can cope with whatever changes needed done to keep the bots green, so I’m happy with that.

6

Thanks @rengolin and @jyknight. Yes, we’re ready to resolve any potential issues for this change.

I just requested a review for this ⚙ D141191 [CMake][LoongArch] Add LoongArch to LLVM_ALL_TARGETS so it is built by default.

1 Like
7

Congrats and thanks for all of the work that went into this!

We’re particularly interesting in supporting builds of the Linux kernel w/ Clang.

I’ve filed an issue here to test it out and provide feedback. Once everything is working, we’ll wire up LoongArch builds in our CI!

2 Likes