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]

Did the RISC-V team agree to provide maintenance for the RV32E* targets?

[hegza]

Oops, I did not mean to imply that 🙂 I'll remove the mention from this file.

[Disasm]

It might be a good idea to move these new comments above so that the list is ordered.

[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