Rollup of 12 pull requests - #161208
Merged
Merged
Conversation
- heavily based on the Sample-based PGO guide for Clang: https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers
- remove pages from the Unstable book for -Zprofile-sample-use and -Zdebuginfo-for-profiling - add corresponding pages to the Rustc codegen docs
- update all related to the flags entities from unstable to stable ones: internal structs, tests
Co-authored-by: 许杰友 Jieyou Xu (Joe) <39484203+jieyouxu@users.noreply.github.com>
The previous implementation of this check would incorrectly inspect any file whose path contains a component named "core", causing false positives in bootstrap.
For `Call` and `InlineAsm` we currently pass `pred` to `apply_call_return_effect`, but for `Yield` we pass `block`. This appears to be a copy/paste error. This currently has no effect because no existing backward analyses look at this argument, but it's worth fixing. There's also a similar case in graphviz.rs.
The edge computation for `Call`, `InlineAsm`, and `Yield` exactly duplicates what is done by `TerminatorKind::edges()`. This commit changes it to use `edges()`; this makes the backward analysis more similar to the forward analysis, which also matches on `TerminatorEdges`. Note: the bug fixed in the previous commit would have been less likely with this new code.
It doesn't need to be `mut`.
Make ShardedHashMap::with_capacity split capacity between shards This makes `ShardedHashMap::with_capacity` split capacity between shards. The callers in `CtxtInterners::new` did not divide these by the shard count, so it reserved 32 times greater capacity, significantly contributing to startup costs. Spotted by Claude Opus while investigating startup stack usage.
…estebank avoid pointless spans in target modifier errors Fixes rust-lang#161174. Currently the diagnostics for target modifier issues always point at the beginning of the first non-empty line in the file. That makes no sense at all IMO since the error has nothing to do with that line: the error is in the CLI flags. So let's just remove this pointless span. While doing this I realized there are other errors also doing this, e.g. `report_incompatible_partial_mitigations` and `report_incompatible_async_drop_feature`. Cc @arielb1 @azhogin why was this done? @rust-lang/wg-diagnostics do you see any reason to have these diagnostics point at `krate.spans.inner_span.shrink_to_lo()`? IMO that is just never a useful thing to do.
…jgillot Analysis cleanups Three small dataflow analysis cleanups. Details in individual commits. r? @cjgillot
…e-use-and-debug-info-for-profiling, r=folkertdev Stabilize `-Zprofile-sample-use` Tracking issue: rust-lang#155668 # Stabilization report ## Summary Sample Profile-Guided Optimization (Sample PGO or SPGO) is an alternative way to perform feedback-directed optimization (FDO). Rustc already supports Instrumented PGO (with the `-Cprofile-generate` / `-Cprofile-use` flags). Downside of the instrumented approach include that it requires a separate compilation and that the instrumentation has significant runtime overhead. SPGO instead uses the output of external profilers like `perf` during the compilation process to perform more aggressive compiler optimizations. This approach is described in [this paper](https://dl.acm.org/doi/abs/10.1145/2854038.2854044). I propose stabilizing `-Zprofile-sample-use` as `-Cprofile-sample-use` More information can be found in the updated by the PR "Profile-guided Optimization" guide or Clang PGO [guide](https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers). These flags are documented as: > - `profile-sample-use`: > > This flag specifies the profiling data file to be used for sample-based > profile-guided optimization (SPGO). The flag takes a mandatory argument which > is the path to a valid `.prof` file. See the chapter on > [profile-guided optimization] for more information. > The `-Zdebuginfo-for-profiling` flag can be used to > improve the quality of the profiling data. For more details about the flag and their usage - check the Profile-guided Optimization guide [change](https://github.com/rust-lang/rust/pull/155942/changes#diff-da79c0293559274602ced76b0d50ab4d56d4eec4dcbb8b59d515b9ae94f26c42). ### What is stabilized One compiler flag: `-Zprofile-sample-use`. ### What isn't stabilized I think this is the right section to compare Sample-based PGO (SPGO) implementation in Rustc vs its "big brother" - Sample-based PGO in Clang. Besides `-Zprofile-sample-use` in Rustc / `-fprofile_sample_use` in Clang and `-Zdebug-info-for-profiling` in Rustc (which we decided to **not** stabilize at the moment) / `-fdebug-info-for-profiling, -fno-debug-info-for-profiling` in Clang, Clang additionally supports the following SPGO-related switches: * `-fpseudo-probe-for-profiling, -fno-pseudo-probe-for-profiling` [flags](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fpseudo-probe-for-profiling). According to the Clang's PGO [guide](https://clang.llvm.org/docs/UsersManual.html#using-sampling-profilers), this switch is optional for SPGO. This switch has originals from an extension of SPGO that is called "Context-sensitive Sample PGO with Pseudo-Instrumentation" or simply "CSSPGO". Here is original [RFC](https://groups.google.com/g/llvm-dev/c/1p1rdYbL93s?pli=1) for the thing, also I can link some LLVM commits/discussions about the topic. This flag is not required for regular SPGO - it's just an improvement idea over regular SPGO, and could be added later to the Rustc in a different process (initially to unstable, than later promoted to stable). But that's another story and we can consider it later. * `-f[no-]unique-internal-linkage-names` [switch](https://clang.llvm.org/docs/UsersManual.html#cmdoption-f-no-unique-internal-linkage-names) is also mentioned in the Clang PGO guide. I don't think that the switch is applicable to Rustc. Correct me if I am wrong pls. * `-fsample-profile-use-profi, -fno-sample-profile-use-profi` [switch](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fsample-profile-use-profi). This switch is also marked as optional in the Clang PGO guide. This switch is an attempt to improve some inaccuracies in SPGO profile with some heuristics. SPGO in Rustc can be easily stabilized without this flag, since it's just a non-critical for regular SPGO usage heuristic. If we decide to add support for this switch to Rustc too - we can do in a separate activity without blocking with stabilization process. Check rust-lang#156898 for more details. * `-fprofile-sample-accurate, -fauto-profile-accurate, -fno-profile-sample-accurate` [switch](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fprofile-sample-accurate). This switch is not mentioned even by the Clang PGO guide :) This flag resolves [this](llvm/llvm-project#63024) issue/feature request from LLVM upstream in SPGO use case. According to the description from Clang: "Specifies that the sample profile is accurate. If the sample profile is accurate, callsites without profile samples are marked as cold. Otherwise, treat callsites without profile samples as if we have no profile". Since we don't specify the flag in Rustc, branches without profile samples are now considered as branches without a profile and optimized as regular release code. Having support for this in Rustc would be definitely a nice addition to be on par with Clang, since there are good use cases for that. But I do not think that this could be a blocker for stabilization of SPGO in Rustc without this functionality - we can add it later. As a proof that SPGO in Rustc works completely okay without it you can use Rust-for-Linux bench [results](https://lore.kernel.org/rust-for-linux/20260331-autofdo-v2-1-eb5c5964820d@google.com/) with SPGO via AutoFDO. I am not aware about any other SPGO-related flags in Clang. We definitely have a gap in SPGO-related flags in Rustc compared to Clang, but none of these gaps is a blocker for stabilization `-Zprofile-sample-use` right now. However, it would be nice to resolve these gaps later: add them in unstable form, test, and later stabilize them to be on par with Clang from SPGO optimization perspective. Right now all the flags above are missing in Rustc even in the unstable form. Stabilization of `-Zprofile-sample-use` **does not** prevent adding all missing SPGO related features later. ## Design ### RFC history No RFC was created for these options. All original discussions for Unstable were done in the original Unstable PR: rust-lang#87918 ### Post-RFC changes > What other user-visible changes have occurred since the RFC was accepted? Describe both changes that the lang team accepted (and link to those decisions) as well as changes that are being presented to the team for the first time in this stabilization report. Compared to the unstable (RFC-like) state, I've made the following changes: * I extended the Rustc's PGO [guide](https://doc.rust-lang.org/beta/rustc/profile-guided-optimization.html) with Sample-based PGO information and instructions, how to use it. This change will resolve rust-lang#117023 . My changes are highly-inspired / cautiously copy-pasted (only needed parts) from the Clang guide. From licensing perspective it should be fine. If it's a problem in any way - I can do some rewording (but I would like to avoid such things). I decided to do some documentation copy due to Sample-based PGO incompatibilities between Clang and Rustc (Clang supports more options at very least). I believe that current version is more user-friendly and easier to use, compared to just referring to the Clang PGO guide. * I changed help message and corresponding documentation for `-Zdebug_info_for_profiling` switch to be in the same way as Clang already [has](https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fdebug-info-for-profiling). It's kinda difficult to describe clearly, what the option does without exposing too much LLVM details - that's why I linked the documentation to the corresponding LLVM pass in the Reference for this option. ### Key points No arguments were raised during stabilization discussion of the feature in any place yet, including Zulip discussion: [#t-compiler > Stabilizing Sample PGO (SPGO): &rust-lang#96;-Zprofile-sample-use&rust-lang#96;](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Stabilizing.20Sample.20PGO.20.28SPGO.29.3A.20.60-Zprofile-sample-use.60/with/590356923) ### Nightly extensions I am not aware of any other unstable SPGO-related switches. ### Doors closed > What doors does this stabilization close for later changes to the language? E.g., does this stabilization make any other RFCs, lang experiments, or known in-flight proposals more difficult or impossible to do later? * Removing Sample-based PGO support from Rustc will be harder. But the technology itself is used on large scales in other ecosystems like Clang (heavily-used in big tech companies internally), and Rust-for-Linux already started to use it even with Rustc. I don't think will be a need to remove it in near future. * Renaming flags will be harder. But current naming is done to be consistent with Clang. Clang proved robustness of this naming, so it shouldn't be a concern either. No other proposals/experiments/etc. are affected. ## Feedback ### Call for testing Call for testing **wasn't** done - it was slightly discussed [#t-compiler > Stabilizing Sample PGO (SPGO): &rust-lang#96;-Zprofile-sample-use&rust-lang#96; @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Stabilizing.20Sample.20PGO.20.28SPGO.29.3A.20.60-Zprofile-sample-use.60/near/590581795). However, no negative feedback was received for stabilization of this feature. Right now this feature is already tested personally by me (local experiments with assembly changes verification before/after applying SPGO on an Intel-based (with LBR) Linux machine in some sample apps with `llvm-profgen` tool and by Rust-for-Linux project in this [patch](https://lore.kernel.org/rust-for-linux/20260331-autofdo-v2-1-eb5c5964820d@google.com/). Additionally, this feature was in unstable state for 5 years (since 2021) with no concerns (due to no bugs or no users - who knows. At least it was implemented for a reason 5 years ). I think that's enough verification for such kind of feature. ### Nightly use The only publicly-known user of this feature is Rust-for-Linux project (see [this](https://lore.kernel.org/rust-for-linux/20260331-autofdo-v2-1-eb5c5964820d@google.com/) commit). Besides that, no other users were found on GitHub via GitHub search for `"-Zprofile-sample-use"` query: almost all found entries are various copies of the Unstable book with the documentation for the option, and other places are related to the Linux kernel. Two found issues are related to the tracking [issue](rust-lang#155668) of these two flags, and corresponding tracking [issue](Rust-for-Linux/linux#2) in Rust-for-Linux. I am not personally aware of any closed-source users of this feature. Probably Google (Sampled-based PGO biggest user at least for C++) and other big techs use it somewhere internally too but it's just a guess. ## Implementation ### Major parts - rust-lang#87918 - unstable original implementation - rust-lang#155942 - this PR, stabilization with some minor changes No significant developments on the Rustc side - just propagating in a proper way SPGO profile to the LLVM part of the compiler. ### Coverage * For `-Cprofile-sample-use` we have only UI tests. We haven't implemented e2e tests since it's will be hard to add them to the current test suite (see the [comment](rust-lang#155942 (comment))) ### Breaking changes No breaking changes are expected from this stabilization. ## History - rust-lang#87918 - initial implementation - rust-lang#156887 - renaming `-Zdebug_info_for_profiling` into `-Zdebuginfo_for_profiling` + adding more tests for the feature (left for the history) - rust-lang#155668 - tracking issue ## Acknowledgments * [Michael Benfield](https://github.com/mikebenfield) - author of the original PR for Unstable * [Jakub Beránek](https://github.com/Kobzol/) - the "PGO guy" in Rustc and `cargo-pgo` author * [Miguel Ojeda](https://github.com/ojeda) - Rust-for-Linux maintainer (they already use Sample-based PGO in Rust-for-Linux) * [Alexander Zaitsev](https://github.com/zamazan4ik) - me I am not aware of any person, who is against stabilization of these two flags. ## Open items I am not aware of any open issue, that is a blocker for stabilization of this feature. List of SPGO-related things, which are **not** stabilization blockers in my opinion: * rust-lang#155525 - this could improve SPGO UX with Rustc, but it's not a strict requirement - an externally-installed `llvm-profgen` can be used instead (I've tested it locally by using `llvm-profgen-21` for SPGO with Rustc 1.95, which is LLVM 22-based
…lacrum Fix std-features example in bootstrap.example.toml
…cote Add regression test for test_case attribute on a use item Closes rust-lang#129765
… r=nnethercote Add regression test for dyn impl missing type closes rust-lang#152668
Add regression test for trait on next solver Closes rust-lang#151306. The new test crashes on commit 37d85e5 (nightly-2026-04-29). The new test fails (but not crashes) due to different stderr since c935696 (nightly-2026-04-30). Ofc the test passes on current version. Also, I took the liberty of adding a few bits of code to the minimal reproduction shared in the original issue just to make the stderr less verbose and we can focus on the issue that really matters. So I added main, removed the lifetimes, etc. It's more code, but I'd argue is easier to reason for a test, although I'd obviously revert back to the minimal example if the reviewer thinks it's best.
tidy: Properly restrict undocumented-unsafe to `library/core` The previous implementation of this check would incorrectly inspect any file whose path contains a component named "core", causing false positives in bootstrap. I noticed this while trying to move some bootstrap code out of `lib.rs` and into a submodule in `crate::core`.
…mprove, r=folkertdev Improve `powerpc-types.rs` test This makes the changes from rust-lang#161135 (except the `min-llvm-version`) that don't require actually adding `f16`/`f128` support. r? @folkertdev
ping me when target ABI checks are being changed The first commit moves the target checks into a separate file, so that the second commit can set up triagebot to ping me when that file gets changed.
rustbot
added
A-LLVM
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 17, 2026
Rollup of 12 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple-* try-job: x86_64-mingw-1 try-job: i686-msvc-*
This comment has been minimized.
This comment has been minimized.
Contributor
rust-bors
Bot
added
merged-by-bors
Contributor
6 tasks
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing eaa160c (parent) -> 8962dda (this PR) Test differencesShow 41 test diffsStage 1
Stage 2
Additionally, 2 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 8962ddaf8ee41101345dcbb63de048f3fa10791e --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (8962dda): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.0%, secondary -8.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -0.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 468.329s -> 457.572s (-2.30%) |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: eaa160c49d In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
-Zprofile-sample-use#155942 (Stabilize-Zprofile-sample-use)library/core#161173 (tidy: Properly restrict undocumented-unsafe tolibrary/core)powerpc-types.rstest #161191 (Improvepowerpc-types.rstest)r? @ghost
Create a similar rollup