Skip to content
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

Rollup of 5 pull requests #97825

Merged
merged 16 commits into from
Jun 7, 2022
Merged

Rollup of 5 pull requests #97825

merged 16 commits into from
Jun 7, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Kixiron and others added 16 commits June 4, 2022 12:33
This is a tiny optimization
It returns the previous work product or panics if there is none. This rename
makes the purpose of this method clearer.
A WorkProduct without a saved file is useless
Co-authored-by: Eduard-Mihai Burtescu <[email protected]>
I was experimenting with cross-language LTO for the wasm target recently
between Rust and C and found that C was injecting the `+mutable-globals`
flag on all functions. When specifying the corresponding
`-Ctarget-feature=+mutable-globals` feature to Rust it prints a warning
about an unknown feature. I've added the `mutable-globals` feature plus
another few I know of to the list of known features for wasm targets.
These features all continue to be unstable to source code as they were
before.
…, r=nagisa

Various refactors to the incr comp workproduct handling

This is the result of me looking into adding support for having multiple object files for a single codegen unit to incr comp. This is necessary to support inline assembly in cg_clif without requiring partial linking which is not supported on Windows and seems to fail on macOS for some reason. Cg_clif uses an external assembler to handle inline asm and thus produces one object file with regular functions and one object file containing compiled inline asm for each codegen unit which uses inline asm. Current incr comp can't handle this. This PR doesn't yet add support for this, but it makes it easier to do so.
…rochenkov

Allow unstable items to be re-exported unstably without requiring the feature be enabled

Closes rust-lang#94972

The diagnostic may need some work still, and I haven't added a test yet
Fix ICEs from zsts within unsized types with non-zero offsets

- Fixes rust-lang#97732
- Fixes ICEs while compiling `alloc` with `-Z randomize-layout`

r? ``@eddyb``
…chenkov

Add some unstable target features for the wasm target codegen

I was experimenting with cross-language LTO for the wasm target recently
between Rust and C and found that C was injecting the `+mutable-globals`
flag on all functions. When specifying the corresponding
`-Ctarget-feature=+mutable-globals` feature to Rust it prints a warning
about an unknown feature. I've added the `mutable-globals` feature plus
another few I know of to the list of known features for wasm targets.
These features all continue to be unstable to source code as they were
before.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 7, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Jun 7, 2022

📌 Commit 9526653 has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 7, 2022
@bors
Copy link
Contributor

bors commented Jun 7, 2022

⌛ Testing commit 9526653 with merge 7fe2c4b...

@bors
Copy link
Contributor

bors commented Jun 7, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 7fe2c4b to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 7, 2022
@bors bors merged commit 7fe2c4b into rust-lang:master Jun 7, 2022
@rustbot rustbot added this to the 1.63.0 milestone Jun 7, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7fe2c4b): comparison url.

Instruction count

  • Primary benchmarks: 😿 relevant regressions found
  • Secondary benchmarks: no relevant changes found
mean1 max count2
Regressions 😿
(primary)
0.2% 0.3% 4
Regressions 😿
(secondary)
N/A N/A 0
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) 0.2% 0.3% 4

Max RSS (memory usage)

Results
  • Primary benchmarks: mixed results
  • Secondary benchmarks: 😿 relevant regression found
mean1 max count2
Regressions 😿
(primary)
1.2% 1.2% 1
Regressions 😿
(secondary)
3.6% 3.6% 1
Improvements 🎉
(primary)
-2.9% -2.9% 1
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) -0.9% -2.9% 2

Cycles

Results
  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 😿 relevant regression found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
2.9% 2.9% 1
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) N/A N/A 0

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

@rustbot rustbot added the perf-regression Performance regression. label Jun 7, 2022
@pnkfelix
Copy link
Member

stm32f4-0.14.0 regressed for check+debug+opt on incr-patched: negate. diesel-1.4.8 regressed for check on incr-patched: println

Given that all the regressions are to incremental, I'm assuming this is because of #97058

@pnkfelix
Copy link
Member

Skimming over #97058, nothing stands out as being an obvious cause for a regression, even a small one.

@pnkfelix
Copy link
Member

skimming over the perf details for stm32f4 check, it seems like the bulk of the time delta is coming from expand_crate. A total time delta of 0.66, and the biggest contributors to that delta are expand_crate (0.033), incr_comp_load_dep_graph (0.015), misc_checking_1 (0.007), hir_owner_nodes (0.005), generate_crate_metadata (0.005), incr_comp_encode_dep_graph (0.004), and wf_checking (0.004). The remainder are <= 0.003, most of them <= 0.000.

@pnkfelix
Copy link
Member

given the relatively small size and scope of the regression, and the fact that it was in a rollup, I do not think this is worth investigating further.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Jun 14, 2022
JohnTitor pushed a commit to JohnTitor/rust that referenced this pull request Jul 26, 2022
Rollup of 5 pull requests

Successful merges:

 - rust-lang#97058 (Various refactors to the incr comp workproduct handling)
 - rust-lang#97301 (Allow unstable items to be re-exported unstably without requiring the feature be enabled)
 - rust-lang#97738 (Fix ICEs from zsts within unsized types with non-zero offsets)
 - rust-lang#97771 (Remove SIGIO reference on Haiku)
 - rust-lang#97808 (Add some unstable target features for the wasm target codegen)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants