Initial support for riscv32{e|em|emc}_unknown_none_elf

[hegza]

We have a research prototype of an RV32EMC target and have been successfully running the e, em, emc programs on it. I'm hoping upstreaming this configuration would make the target maintenance slightly easier.

Configuration is based on the respective {i, im, imc} variants. As defined in RISC-V Unprivileged Spec. 20191213, the only change in RVE wrt. RVI is to reduce the number of integer registers to 16 (x0-x15), which also implies

• 2 callee saved registers instead of 12
• 32-bit / 4-byte stack alignment instead of 128 bits / 16 bytes

My initial presumption is that this will not impact how the target is defined for the compiler but only becomes relevant at the runtime level. I am willing to investigate, though.

EDIT: LLVM is now told about the presumed 32-bit stack alignment.

@Disasm @romancardenas

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nnethercote (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

These commits modify compiler targets.
(See the Target Tier Policy.)

[hegza]

error: data-layout for target riscv32e-unknown-none-elf, e-m:e-p:32:32-i64:64-n32-S32, differs from LLVM target's riscv32 default layout, e-m:e-p:32:32-i64:64-n32-S128

Apparently this test case wants the stack to be 128-bit aligned as is the default behavior on RISC-V. I revert back to 128-bit stack alignment to respect the test case.

[hegza]

@rustbot label +O-riscv

[nnethercote]

Seems plausible, but I will defer to people who know much more about targets than I do:

r? @Noratrieb
cc @workingjubilee

[workingjubilee]

@hegza Can you write a test that uses asm! and verifies that trying to use the invalid-to-address registers on rv32e is an error? Or do we already have that? Just so that, you know, we can confirm we're probably not generating wildly incorrect code.

[workingjubilee]

@hegza Can you look into what this "assembly-based tools only" means? https://github.com/llvm/llvm-project/blob/8c3b94f420a20a45dd07f3e12d6a6d649858f452/llvm/docs/RISCVUsage.rst#base-isas

Apparently this test case wants the stack to be 128-bit aligned as is the default behavior on RISC-V. I revert back to 128-bit stack alignment to respect the test case.

That is probably not what should be happening. That test case is to validate we can at least produce a binary for the target, which has in the past proved surprisingly challenging for some direly under-maintained targets. You are instead running into an internal assertion to guarantee we match LLVM's data layout. But that's not the correct layout for the target if it is demanding a 16-byte stack. What is LLVM's data layout string for RISCV32E targets?

[workingjubilee]

You can find that assertion here if you care to investigate why we might be getting the wrong(?) data layout string:

rust/compiler/rustc_codegen_llvm/src/context.rs

Lines 141 to 161 in 5793a9e

	// Ensure the data-layout values hardcoded remain the defaults.
	{
	let tm = crate::back::write::create_informational_target_machine(tcx.sess, false);
	unsafe {
	llvm::LLVMRustSetDataLayoutFromTargetMachine(llmod, &tm);
	}
	let llvm_data_layout = unsafe { llvm::LLVMGetDataLayoutStr(llmod) };
	let llvm_data_layout =
	str::from_utf8(unsafe { CStr::from_ptr(llvm_data_layout) }.to_bytes())
	.expect("got a non-UTF8 data-layout from LLVM");
	if target_data_layout != llvm_data_layout {
	tcx.dcx().emit_err(crate::errors::MismatchedDataLayout {
	rustc_target: sess.opts.target_triple.to_string().as_str(),
	rustc_layout: target_data_layout.as_str(),
	llvm_target: sess.target.llvm_target.borrow(),
	llvm_layout: llvm_data_layout,
	});
	}
	}

[workingjubilee]

We can either fix this to be correct for the RV32E targets...

[workingjubilee]

Or we can add documentation that we don't actually generate code with a 4-byte stack alignment, but rather to a 16-byte stack alignment, which is I guess technically acceptable even if it is incorrect.

[Disasm]

32-bit stack alignment seems to be defined by the ABI (https://github.com/llvm/llvm-project/blob/528bcf3a55ca520c31c77ed5fbacf09bff8f39ec/clang/lib/Basic/Targets/RISCV.h#L145-L150) so it might be a good idea to explicitly define llvm_abiname as ilp32e.

[workingjubilee]

That's clang's code, not LLVM.

[Disasm]

My bad, but there are also similar lines in the other parts of the LLVM code: https://github.com/llvm/llvm-project/blob/5b17f85a7d722439a39f1ac1c554aed7858adab4/llvm/lib/Target/RISCV/RISCVTargetMachine.cpp#L145-L146

[workingjubilee]

yeah, you are nonetheless correct: https://github.com/llvm/llvm-project/blob/5b17f85a7d722439a39f1ac1c554aed7858adab4/llvm/lib/Target/RISCV/RISCVFrameLowering.cpp#L30-L36

[Noratrieb]

r? workingjubilee

[workingjubilee]

@rustbot author

[hegza]

@hegza Can you look into what this "assembly-based tools only" means? https://github.com/llvm/llvm-project/blob/8c3b94f420a20a45dd07f3e12d6a6d649858f452/llvm/docs/RISCVUsage.rst#base-isas

Seems to be explained later in the same file. I believe that it means that LLVM supports the associated instructions in assembly, including assembler, disassembler, llvm-objdump, etc. Compiler & linker accept the extension and binaries have relevant ELF flags.

I infer that "assembly-based tools only" means the following are not included: C-language intrinsics & pattern matching by the compiler to recognize idiomatic patterns which can be lowered to associated instructions.

They also state specifically about E:

Support of RV32E/RV64E and ilp32e/lp64e ABIs are experimental. To be compatible with the implementation of ilp32e in GCC, we don't use aligned registers to pass variadic arguments. Furthermore, we set the stack alignment to 4 bytes for types with length of 2*XLEN.

[hegza]

@bors r=@workingjubilee

^ Doing as requested although I'm not 100 % sure what that means. Bors-NG doc says it "records you as the reviewer in the commit log".

Fixups as requested. Rebased to track master & squash fixups.

[bors]

📌 Commit 6edd0b3 has been approved by workingjubilee

It is now in the queue for this repository.

[hegza]

Ah, I see! It has to do with the bors delegate+. I think I figured it out 😺

[p-kraszewski]

Does any of the targets cover RV32EC, as found in CH32V003 series and other ultracheap RV microcontrollers?

[hegza]

Ah, I had heard rumors about this specific E-target already existing in the wild.

No, this target mainly covers the base ISA E and the EMC ISA used in our prototype, core. I decided to also include EM as there's sometimes use for that due to our outdated debug module being unable to handle compressed instructions. The raison d'être for this PR is that we currently tend to need both the newest features from latest Rust and the RV32E backend so after a couple of rather laborious rebases I figured it's easier to maintain this patch in-tree than out-of-tree.

Extension to EC would be trivial. However, with RISC-V ISA, the extension combinations will probably keep on coming ad nauseam so I'd like to push back adding targets just for completeness sake. I've been maintaining Rust targets for a grand total of one week so I'm not 100 % sure on the best practices here but I think that if you think it's a good idea to add riscv32ec, please open an issue (or a PR) and ping me so we can give an opportunity for comments and build buy-in. I lean on agreeing, as I think it would be good to have the RV32EC target as that is most likely the most common target in the wild.

[workingjubilee]

We are in fact trying to move away from adding more targets and towards a framework for stabilizing a sort of "vertical slice" of -Zbuild-std aimed at this sort of thing (more like -Zbuild-core, in effect) precisely because the already-added selection of RISCV targets is frankly, way too many.

So.

Use nightly, use -Zbuild-std, report bugs, fix them, and none of the targets ever will need to support yonder bespoke RISCV ISA.

[rmsyn]

32-bit stack alignment seems to be defined by the ABI (https://github.com/llvm/llvm-project/blob/528bcf3a55ca520c31c77ed5fbacf09bff8f39ec/clang/lib/Basic/Targets/RISCV.h#L145-L150) so it might be a good idea to explicitly define llvm_abiname as ilp32e.

It looks like LLVM is following GCC here, from llvm/llvm-project@3ac9fe6:

To be compatible with the implementation of ilp32e in GCC, we don't use
aligned registers to pass variadic arguments and set stack alignment\
to 4-bytes for types with length of 2*XLEN.

The GCC implementation is here: https://github.com/gcc-mirror/gcc/blob/d136fa00f0d5faff8397edcd7e4ebb3445ab21b0/gcc/config/riscv/riscv.h#L202-L205

The ABI stack alignment doesn't appear to be specified in the current RV32E/RV64E specification, so maybe this choice by GCC is based on soft-core FPGA implementations and/or chips like CH32V003 as @p-kraszewski mentioned? I'd be interested to find out what the GCC author(s) based their changes on.