Add riscv64gc-unknown-linux-gnu target

[msizanoen1]

This PR add the target, but doesn't build std on CI yet.
I have a port for libc crate and std which I will upstream soon after this target is added.

r? @alexcrichton

[msizanoen1]

I have successfully compiled std for this target using my ports.
std port: https://github.com/msizanoen1/rust/tree/riscv-std
libc crate port: https://github.com/msizanoen1/libc/tree/riscv
To test, create a local branch, then merge this PR and the std port branch then add a patch for libc in workspace manifest to point to my libc branch like this:

# Under [patch.crates-io]
libc = { git = "https://github.com/msizanoen1/libc.git", branch = "riscv" }

and run cargo update -p libc.
I still have not figured out how to run the test though.

[msizanoen1]

Also to build std you need the cross toolchain which you can build using crosstool-ng.
You need to set CFLAGS_riscv64gc_unknown_linux_gnu to -mabi=lp64d -fPIC.

[msizanoen1]

I have managed to get rustc and cargo to build for riscv64 using the std and the libc ports and also made minor fixes to the libc port at the same time.

[msizanoen1]

The current riscv backend in LLVM 9 should be mature enough to compile big applications like rustc and cargo for running under linux: https://www.lowrisc.org/blog/2019/07/risc-v-llvm-backend-in-clang-llvm-9.0/

[msizanoen1]

@rustbot modify labels: +O-riscv

[alexcrichton]

@bors: r+

[bors]

📌 Commit 75dac38 has been approved by alexcrichton

[lenary]

The required lowering for the lp64d risc-v is (to my understanding) not yet implemented. It is unlikely you will be able to correctly call or return from C (or other language) functions that have floating point argument or return types.

[msizanoen1]

It is implemented in LLVM 9 (which is the version used by rustc) now.

[msizanoen1]

rust-lang/llvm-project@0b2803e

[msizanoen1]

The frontend lowering code is here: https://github.com/rust-lang/rust/blob/master/src/librustc_target/abi/call/riscv.rs
It does not handle hard float specifically but it shouldn't be a problem until somebody needs to use ilp32q (128-bit floating point on 32-bit RISC-V) (edit: it does not exist).

[lenary]

@msizanoen1 as is pointed out in the commit message on rust-lang/llvm-project@0b2803e:

A number of aspects of the RISC-V float hard float ABIs require frontend
support (e.g. flattening of structs and passing int+fp for fp+fp structs in a
pair of registers), and will be addressed in a Clang patch.

To elaborate: Clang generates slightly different LLVM IR depending on the ABI chosen. Unfortunately the LLVM IR to RISC-V Machine Code translation is too late for some of the ABI details needed to do the lowering from C to RISC-V machine code correctly. This is an LLVM problem common to all backends, not just RISC-V. The RISC-V ABI lowering implementation in clang is here: https://github.com/llvm/llvm-project/blob/8e780252a7284be45cf1ba224cabd884847e8e92/clang/lib/CodeGen/TargetInfo.cpp#L9311-L9773

It has been on my list to make the same changes to rustc that clang has in order to support this ABI. I have not yet got around to doing so. This means if you are calling C code, or other code that follows the RISC-V ELF psABI, you will have issues around passing floats to and from rust code, even if the function is marked extern "C".

Rust code that calls other rust code is allowed to do whatever it wants, as that is entirely handled by rustc.

For context: I work at lowRISC on LLVM for RISC-V. I would love full support for RISC-V in rustc (which is why fixing this is on my todo list), but I also want to be accurate about what rustc supports for RISC-V and where its implementation is not complete.

[msizanoen1]

It seems like LLVM has the behavior to unwrap aggreates in structs passed in arguments by default so it will only be a problem when FLEN > XLEN, which rustc has not handle yet.

[msizanoen1]

This is my translation of the Clang lowering logic in Rust: https://github.com/msizanoen1/rust/blob/riscv-abi/src/librustc_target/abi/call/riscv.rs
Rustc does not deconstruct argument by itself but rely on LLVM to do it.

[lenary]

The lowering logic PR is #68452.