Repository navigation
Rollup of 7 perf-sensitive pull requests - #165244
Conversation
We can add ADTs to the early return check by avoiding the cases where `coerce_unsized_info` can succeed with ADTs. - It only succeeds if the ADTs are structs, which means we can return early for enums and unions. - It only succeeds if the ADTs are the same struct but differ in a field type, which means we can return early for non-generic structs.
It currently wraps `coerce_unsized` but that function has a number of early returns that don't need the `commit_if_ok`. This commit moves the `commit_if_ok` inside of `coerce_unsized`, to wrap just the part that needs it.
…econstruction, r=tmiasko MIR move elimination [5/6]: Storage reconstruction Depends on rust-lang#163338 This PR extends the `MoveElimination` pass from rust-lang/rfcs#3943 to reconstruct `StorageLive`/`StorageDead` statements for all locals by using the liveness information collected by `PreciseLiveness`. r? tmiasko
…alization, r=dianqk MIR move elimination [1.5/6]: Ensure ZSTs are always initialized Split off from rust-lang#163335 The new MIR semantics from rust-lang/rfcs#3943 require that a local be initialized before it is used, since it only gains an allocation at that point. This means that ZSTs must be initialized before being read, even though the initialization is a no-op in codegen. This PR addresses this in 2 ways: - Adds missing ZST initializations in MIR shims and MIR intrinsic lowering. - Restricts the `RemoveZsts` pass to only remove ZST assignments when the destination is indirect, since such places are required to already be allocated anyways. This is fine in practice since dead ZST assignments are later removed by DSE. The last one also exposed a limitation in `SimplifyMatch`'s handling of constant equality when checking if two match arms are equivalent: it was only checking for scalar constants and was not handling `()` unit constants, which resulted in a test regression. The pass has been fixed to handle any kind of `ConstValue`. r? tmiasko
…rochenkov Move lang item collection to the resolver The separate query had to walk the entire ast again, also tracking owners and converting NodeIds to DefIds. I think it's nicer to just do it as part of the resolver. Alternatively we could limit the lang item collection to the local ones and keep the query. Instead of walking the current crate again we'd just take the list from the resolver query just like we take the list from upstream crates.
… r=BoxyUwU do not prefer trivially true candidates with `-Znext-solver` This is for the sake future compatibility, see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/resolving.20equal.20regions/near/623504310 for more background. Integrated changes to make this not cause any crater regression, see rust-lang#133502 (comment) where we did an accidental crater run only for this change. I would generally like us to not be region dependent at all. For this we need the following: - `stalled_on` shouldn't have to track region variables - my hope is that we can yeet region uniquification once we have OR constraints For this to work candidate merging has to always merge the region constraints of all candidates and can't rely on there being no region constraints. This in turn means that as long as there's an ambiguous candidate, we can't use another candidate which is known to hold, as the ambiguous candidate may end up resulting in fewer region constraints than the existing options. This change does prevent us from discarding `HeadUsages` of other where-bounds if one where-bound holds without any constraints. This will cause hangs if we allow using a non-rigid `ParamEnv` for normalization in rust-lang/trait-system-refactor-initiative#210. This also has annoying interactions with weakening impl shadowing. I am really unsure about the long-term plan here. We may revert this change in the future because the tradeoff isn't worth it, unsure. By doing it for now we're future compatible with whatever we want to do. The cycle handling tests are better tested by https://github.com/lcnr/search_graph_fuzz, having subtle cycle handling tests as ui tests is very brittle and very easily stops testing the right thing. cc rust-lang/trait-system-refactor-initiative#305, see the added test r? types
…eturn, r=ShoyuVanilla Expand an early return case in `coerce_unsized` Details in individual commits. r? @lcnr
…nnethercote Use adaptive sparse encoding for metadata tables r? @nnethercote I have added this implementation partially following the approach suggested in the existing FIXME comment. Each 64-element block stores a cumulative count of preceding non-default values, enabling constant-time lookup by combining that count with a popcount of the bitmap bits before the requested position. In local measurements, `.rmeta` file sizes decreased for all four crates in both Check and Release builds: | Crate | Check reduction | Release reduction | |---|---:|---:| | tokio | 33.68% | 27.25% | | tokio-util | 29.18% | 21.93% | | serde_core | 34.45% | 18.37% | | serde_json | 27.07% | 16.96% | LLM disclosure: I used an LLM for some of the analysis in this PR.
destringlyfy lint infrastructure
Currently, lints are passed as strings and parsed/split/reformatted/compared/etc in many many places. It's not always clear whether that string includes the tool or not.
Instead, they are passed around as:
```rust
pub struct LintName {
pub tool: Option<Symbol>,
pub name: Symbol,
}
```
r? @JonathanBrouwer
Rollup of 7 perf-sensitive pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-msvc-1 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu try-job: test-x86_64-gnu-llvm-22-3 try-job: test-aarch64-msvc-2
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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 f9ceb4a (parent) -> 6fdaa71 (this PR) Test differencesShow 92 test diffsStage 1
Stage 2
Additionally, 72 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 6fdaa715ca3b01ce517f3499d2396978fa413f5d --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 |
|
Finished benchmarking commit (6fdaa71): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@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 -3.8%, secondary -4.2%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.9%, secondary -2.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.6%, secondary 0.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 492.484s -> 487.673s (-0.98%) |
|
📌 Perf builds for each rolled up PR:
parent commit: f9ceb4a4d4 In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
|
@rust-timer triage all |
Running triage with 57 benchmarksTriage only executes the benchmarks on rollup members, that were changed significantly on the rollup.
#163339 81111e9 MIR move elimination [5/6]: Storage reconstructionInstruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (primary 0.9%, secondary -2.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. #163359 c00686c MIR move elimination [1.5/6]: Ensure ZSTs are always initializedInstruction 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.5%, secondary 1.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 3.8%, secondary -0.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary 0.8%, secondary 0.6%)A less reliable metric. May be of interest, but not used to determine the overall result above.
#163525 b2696b2 Move lang item collection to the resolverQueued b2696b2 with parent f9ceb4a, future comparison URL. #163928 ba762b4 do not prefer trivially true candidates with
|
Successful merges:
-Znext-solver#163928 (do not prefer trivially true candidates with-Znext-solver)coerce_unsized#164341 (Expand an early return case incoerce_unsized)r? @ghost
Create a similar rollup