-
Couldn't load subscription status.
- Fork 13.9k
Port most of --print=target-cpus to Rust
#132514
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
r? @nnethercote rustbot has assigned @nnethercote. Use |
|
This PR modifies cc @jieyouxu |
64d4573 to
1320d7b
Compare
|
There is only one existing test for this flag ( Adding snapshot-based tests for this seems like it would be a maintenance nightmare, so I wrote it as a custom run-make test that only checks the start of the output, and ignores the specific host CPU name. |
| // Now try some cross-target queries with the same arch as the host. | ||
| // (Specify multiple targets so that at least one of them is not the host.) | ||
| let cross_targets: &[&str] = if cfg!(target_arch = "aarch64") { | ||
| &["aarch64-unknown-linux-gnu", "aarch64-apple-darwin"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: ... would this need needs-llvm-component
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm not sure.
My guess is no, because it's guaranteed by ignore-cross-compile that we at least have the relevant arch component for the host system, and we're only testing other targets with the same arch as the host.
But I know very little about LLVM components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I asked because I have dealt with run-make tests that seemed innocent (like see #129390). Apparently even --print=target-list needed relevant llvm components to be available.
So I think we should have the //@ needs-llvm-components for the cross-compiled targets: usually we have them (e.g. CI LLVM or locally), so it would be trivially satisfied.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the condition will usually be true in CI and locally, then I don't mind adding the directive as a precaution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's mostly just that some contributors do build local llvms without unneeded components.
1320d7b to
90f2075
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this LGTM, feel free to r=me after PR CI is green.
|
🟩 @bors r=jieyouxu |
…ouxu Port most of `--print=target-cpus` to Rust The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer. This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.
…kingjubilee Rollup of 12 pull requests Successful merges: - rust-lang#132393 (Docs: added brief colon explanation) - rust-lang#132419 (PassWrapper: adapt for llvm/llvm-project@b01e2a8b5620466c3b) - rust-lang#132437 (coverage: Regression test for inlining into an uninstrumented crate) - rust-lang#132458 (get rid of a whole bunch of unnecessary rustc_const_unstable attributes) - rust-lang#132499 (unicode_data.rs: show command for generating file) - rust-lang#132503 (better test for const HashMap; remove const_hash leftovers) - rust-lang#132514 (Port most of `--print=target-cpus` to Rust) - rust-lang#132520 (NFC add known bug nr to test) - rust-lang#132522 (make codegen help output more consistent) - rust-lang#132523 (Added regression test for generics index out of bounds) - rust-lang#132526 (Subtree sync for rustc_codegen_cranelift) - rust-lang#132528 (Use `*_opt` typeck results fns to not ICE in fallback suggestion) - rust-lang#132540 (Do not format generic consts) Failed merges: - rust-lang#132511 (stabilize const_arguments_as_str) r? `@ghost` `@rustbot` modify labels: rollup
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (59ae5eb): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary 4.4%, secondary 0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary 2.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 779.49s -> 779.022s (-0.06%) |
The logic and formatting needed by
--print=target-cpushas historically been carried out in C++ code. Originally it usedprintfto write directly to the console, but later it switched over to writing to astd::ostringstreamand then passing its buffer to a callback function pointer.This PR replaces that C++ code with a very simple function that writes a list of CPU names to a
&RustString, with the rest of the logic and formatting being handled by ordinary safe Rust code.