Initial support for riscv32{e|em|emc}_unknown_none_elf by hegza · Pull Request #130555 · rust-lang/rust (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation55 Commits8 Checks6 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

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

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 rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-bootstrap

Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

labels

Sep 19, 2024

@rustbot

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

cc @Noratrieb

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

@rust-log-analyzer

This comment has been minimized.

@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

@nnethercote

@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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

// Ensure the data-layout values hardcoded remain the defaults.
{
let tm = crate:🔙: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,
});
}
}
pub(crate) fn target() -> Target {
Target {
data_layout: "e-m:e-p:32:32-i64:64-n32-S128".into(),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can either fix this to be correct for the RV32E targets...
**Tier: 2**
Bare-metal target for RISC-V CPUs with the RV32I, RV32IM, RV32IMC, RV32IMAFC and RV32IMAC ISAs.
**Tier: 3**
Bare-metal target for RISC-V CPUs with the RV32IMA ISA.
Bare-metal target for RISC-V CPUs with the RV32IMA, RV32E, RV32EM and RV32EMC ISAs.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Disasm

@Disasm

@workingjubilee

That's clang's code, not LLVM.

@Disasm

@workingjubilee

@Noratrieb

@workingjubilee

@rustbot rustbot added S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

and removed S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

labels

Sep 26, 2024

@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

Add rv32e-targets to 'stage0 missing targets'. This prevents the error "no such target exists in the target list".

@hegza

@hegza

@hegza

@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.

@bors bors added S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

and removed S-waiting-on-author

Status: This is awaiting some action (such as code changes or more information) from the author.

labels

Oct 5, 2024

@hegza

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

bors added a commit to rust-lang-ci/rust that referenced this pull request

Oct 5, 2024

@bors

…iaskrgr

Rollup of 5 pull requests

Successful merges:

r? @ghost @rustbot modify labels: rollup

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Oct 5, 2024

@rust-timer

Rollup merge of rust-lang#130555 - hegza:rv32e, r=workingjubilee

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

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

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

@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.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Oct 27, 2024

@workingjubilee

…-mislinked, r=tgross35

docs: Correctly link riscv32e from platform-support.md

Correctly link the riscv32e platform support page.

Just a mistake during the iteration of rust-lang#130555 that was missed in review. Presumably the rv32e-none and rv32i-none pages eventually should get merged, but this is a relatively recent addition to the ISA definition so it is not clear the current RISCV Embedded group has the expertise on-hand... nor did it have their consent.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request

Oct 27, 2024

@workingjubilee

…-mislinked, r=tgross35

docs: Correctly link riscv32e from platform-support.md

Correctly link the riscv32e platform support page.

Just a mistake during the iteration of rust-lang#130555 that was missed in review. Presumably the rv32e-none and rv32i-none pages eventually should get merged, but this is a relatively recent addition to the ISA definition so it is not clear the current RISCV Embedded group has the expertise on-hand... nor did it have their consent.

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Oct 27, 2024

@rust-timer

Rollup merge of rust-lang#132205 - workingjubilee:rv32e-platform-docs-mislinked, r=tgross35

docs: Correctly link riscv32e from platform-support.md

Correctly link the riscv32e platform support page.

Just a mistake during the iteration of rust-lang#130555 that was missed in review. Presumably the rv32e-none and rv32i-none pages eventually should get merged, but this is a relatively recent addition to the ISA definition so it is not clear the current RISCV Embedded group has the expertise on-hand... nor did it have their consent.

@cuviper cuviper added the relnotes

Marks issues that should be documented in the release notes of the next release.

label

Nov 21, 2024

wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this pull request

Nov 30, 2024

@he32

Pkgsrc changes compared to rust182:

TODO:

Upstream changes:

Version 1.83.0 (2024-11-28)

Language

Compiler

Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

tmeijn pushed a commit to tmeijn/dotfiles that referenced this pull request

Dec 5, 2024

@tmeijn

This MR contains the following updates:

Package Update Change
rust minor 1.82.0 -> 1.83.0

MR created with the help of el-capitano/tools/renovate-bot.

Proposed changes to behavior should be submitted there as MRs.

Release Notes

rust-lang/rust (rust)

v1.83.0

Compare Source

==========================

Language

Compiler

Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about this update again.

This MR has been generated by Renovate Bot.

@hegza hegza mentioned this pull request

Dec 12, 2024

@rmsyn

netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request

Feb 24, 2025

@he32

Pkgsrc changes:

Upstream changes:

Version 1.83.0 (2024-11-28)

Language

Compiler

Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support.

Libraries

Stabilized APIs

These APIs are now stable in const contexts:

Cargo

Rustdoc

Compatibility Notes

Labels

O-riscv

Target: RISC-V architecture

relnotes

Marks issues that should be documented in the release notes of the next release.

S-waiting-on-bors

Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

T-bootstrap

Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)

T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.