compiler-team
compiler-team copied to clipboard
rust-lang
Add support for the LoongArch architecture
Proposal
tl;dr: Make LoongArch a new supported architecture, initially supporting the following 2 tuples:
| Target | Notes | Eventual tier |
|---|---|---|
loongarch64-unknown-linux-gnuf64 |
LoongArch LA64, Linux, LP64D ABI (kernel 5.19, glibc TBD, expected 2.36) | Tier 2 with host tools |
loongarch64-unknown-linux-muslf64 |
LoongArch LA64, Linux, LP64D ABI (kernel 5.19, musl TBD) | Tier 2 |
after the LoongArch ports of LLVM, glibc and musl fully land.
LoongArch is a new RISC architecture developed by the Loongson Technology Corporation, with pretty complete upstream support (binutils 2.38, gcc 12.1.0, linux v5.19-rc1, qemu 7.1). Ports for LLVM, glibc and musl are already under review, I'm one of the reviewers so I'll update this whenever new progress happens.
This architecture already has a small but growing user base in China, that mainly consists of software porters and hobbyist end-users for now (June 2022). Growth is expected to continue in the coming years, expanding to the general consumer market. The architecture is capable of full-fledged desktop and server workload alike, in addition to SoC models intended for embedded.
Latest version of the LoongArch ELF psABI specification can be found here, while current toolchain convention document is available here. The ISA manual (currently revision v1.00) is here; new ISA revisions are expected to keep backwards compatibility so we don't need to encode the revision in the target tuple (ideally just configure target-cpu just like any other arch).
The LoongArch ABI is modeled after that of RISC-V, so there are 6 ABIs in total (LP64/ILP32; soft-float, SP/DP hard-float). The only fully developed ABI is LP64D, others are mostly unusable right now. According to the toolchain convention doc, the Debian multiarch tuples for LP64D are loongarch64-linux-gnuf64 (glibc) and loongarch64-linux-muslf64 (musl) respectively, so we should pick loongarch64-unknown-linux-gnuf64 and loongarch64-unknown-linux-muslf64 for the Rust tuples.
Eventually, the loongarch64-unknown-linux-gnuf64 target should reach Tier 2 with host tools status, because this platform can, and is used, for serious development work, but is not expected to gain enough adoption to be considered Tier 1. The musl target should eventually get to Tier 2 as well; but for the initial bring-up, starting at Tier 3 is expected, for the code to gradually appear and settle.
I'm posting this before all the necessary ports (esp. LLVM) are ready, for convenience and early comments. Some of the ports were rushed (as is the architecture itself), and we really don't want to rush another project.
(Disclaimer: I'm not affiliated with Loongson or any of the Loongson ecosystem companies.)
Mentors or Reviewers
I haven't done serious Rust work recently (my last serious change predated the MCP process, actually) so I don't know who to put here; but I can mentor or do the whole port myself (I polished the Rust MIPS support back in 2015/16, and the basic flow hasn't changed since).
Process
The main points of the Major Change Process are as follows:
- [x] File an issue describing the proposal.
- [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
cc @rust-lang/compiler @rust-lang/compiler-contributors
I have a "working" rustc fork for LoongArch: https://github.com/xry111/rust/tree/xry111/loongarch-1.61.0. At least it can compile Spidermonkey and librsvg so I can make GNOME running on my LoongArch board.
The rustc fork currently depends on a LLVM fork with patches authored by Loongson people and rebased & adjusted by me: https://github.com/xry111/llvm-project/tree/xry111/loongarch-14
I don't expect a very soon ending of LLVM upstreaming process (the code generation for integer arithmetics was just submitted for review yesterday), so I'll try libgccjit codegen next. If libgccjit works hopefully we won't be blocked by LLVM.
Another blocker is glibc. As long as glibc port is not merged, we cannot submit rust binding for libc code for review. The libc crate is needed by std crate. But thanks to your effort I think glibc LoongArch port may be merged before Aug :).
All deleted as all my work shall be superseded now.
