Skip to content

Port stdarch-gen-loongarch to stdarch-gen-common harness#2178

Open
xonx4l wants to merge 4 commits into
rust-lang:mainfrom
xonx4l:port-loongarch
Open

Port stdarch-gen-loongarch to stdarch-gen-common harness#2178
xonx4l wants to merge 4 commits into
rust-lang:mainfrom
xonx4l:port-loongarch

Conversation

@xonx4l

@xonx4l xonx4l commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

This PR ports stdarch-gen-loongarch to stdarch-gen-common harness.

The change in main invokes run_generator once per committed dir when called with no args or lsx/lasx.

The CI switches from -- <spec> to -- lsx / -- lasx with STDARCH_GEN_MODE=check.

Swapped the first two comment lines of lsx/tests.rs and lasx/tests.rs so the auto-generated marker moves to line 2 . So discover_owned only checks the first line and makes the harness skip tests.rs which is not produced by stdarch-gen-loongarch .

r? @folkertdev

@Kobzol Kobzol left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Looks reasonable, thanks! I suppose that we could just generate even the spec and tests using the new stdarch-gen-common machinery? Or do they differ somehow from gen_bind?

View changes since this review

STDARCH_GEN_MODE: check
run: |
cargo run --bin=stdarch-gen-loongarch --release -- crates/stdarch-gen-loongarch/lsx.spec
cargo run -p stdarch-gen-loongarch --release -- lsx

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Ultimately, this will still be a bit annoying to replicate in bootstrap, as we have to ensure that we invoke both the right crates, and with the right arguments.

That is not for this PR, but I'd think about merging everything into a single binary that will generate everything, I think that would be easier to work with.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Agreed.

@@ -1,5 +1,5 @@
// This code is automatically generated. DO NOT MODIFY.
// See crates/stdarch-gen-loongarch/README.md
// This code is automatically generated. DO NOT MODIFY.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Since the tests.rs files are not generated using the stdarch-gen-common machinery, let's use a different header for them, to avoid this line moving hack.

By the way, if you regenerate the Loongarch tests.rs files now, are they the same as they committed versions?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Added a different header . As for regenerating the tests.rs i haven't actually run it. Thank you!

@folkertdev

Copy link
Copy Markdown
Contributor

cc @heiher

@heiher

heiher commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

Thanks! LoongArch SIMD intrinsics are being gradually migrated to intrinsics::simd to make them easier for Miri to execute. These portable impls are handwritten rather than generated, so the LoongArch SIMD code generator is expected to be phased out.

@folkertdev

Copy link
Copy Markdown
Contributor

so the LoongArch SIMD code generator is expected to be phased out.

I don't think you can eliminate it entirely. Anyhow this is just a heads-up that we're refactoring it a bit to make it easier to run in rust-lang/rust CI.

Comment on lines +1607 to +1612
let harness_exts: Option<&[&str]> = match args.len() {
1 => Some(&["lsx", "lasx"]),
2 if args[1] == "lsx" => Some(&["lsx"]),
2 if args[1] == "lasx" => Some(&["lasx"]),
_ => None,
};

@folkertdev folkertdev Jul 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nitpicky but I think this should work

Suggested change
let harness_exts: Option<&[&str]> = match args.len() {
1 => Some(&["lsx", "lasx"]),
2 if args[1] == "lsx" => Some(&["lsx"]),
2 if args[1] == "lasx" => Some(&["lasx"]),
_ => None,
};
let harness_exts: Option<&[&str]> = match &args {
[_] => Some(&["lsx", "lasx"]),
[_, "lsx"] => Some(&["lsx"]),
[_, "lasx"] => Some(&["lasx"]),
_ => None,
};

View changes since the review

gen_bind(in_file, ext_name)
return gen_spec(in_file, ext_name).map_err(|e| e.to_string());
}
if args.get(2).is_some() {

@folkertdev folkertdev Jul 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
if args.get(2).is_some() {
if let [_, _lsx_or_lasx, _some_name_for_what_this_is] = &args {

I kind of lost what is in args[2] and what it's supposed to indicate.

View changes since the review

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

args[2] is the literal string "test" it flips this into gen_test mode.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
if args.get(2).is_some() {
if let [_, _lsx_or_lasx, "test"] = &args {

is much clearer then.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

YES .

@heiher

heiher commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

so the LoongArch SIMD code generator is expected to be phased out.

I don't think you can eliminate it entirely. Anyhow this is just a heads-up that we're refactoring it a bit to make it easier to run in rust-lang/rust CI.

LoongArch currently generates tests using random input values, with the expected results produced by running them under QEMU. We don't currently fix the random seed, so regenerating the tests produces a different version each time.

If maintaining the LoongArch generator is making this work more difficult, another option would be to simply check in the currently generated code and keep them as-is. In any case, most of them are expected to be rewritten eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants