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 8 pull requests #107343

Merged
merged 19 commits into from
Jan 27, 2023
Merged

Rollup of 8 pull requests #107343

merged 19 commits into from
Jan 27, 2023

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

yanns and others added 19 commits December 29, 2022 11:22
This will allow using miri on simd instructions
rust-lang/stdarch#1347 (comment)
Atomic operations for different widths (8-bit, 16-bit, 32-bit etc.) are
guarded by `target_has_atomic = "value"` symbol (i.e. `target_has_atomic
= "8"`) (and the other derivatives), but before this change, there was
no width-agnostic symbol indicating a general availability of atomic
operations.

This change introduces:

* `target_has_atomic_load_store` symbol when atomics for any integer
  width are supported by the target.
* `target_has_atomic` symbol when also CAS is supported.

Fixes rust-lang#106845

Signed-off-by: Michal Rostecki <[email protected]>
Before this change, the following functions and macros were annotated
with `#[cfg(target_has_atomic = "8")]` or
`#[cfg(target_has_atomic_load_store = "8")]`:

* `atomic_int`
* `strongest_failure_ordering`
* `atomic_swap`
* `atomic_add`
* `atomic_sub`
* `atomic_compare_exchange`
* `atomic_compare_exchange_weak`
* `atomic_and`
* `atomic_nand`
* `atomic_or`
* `atomic_xor`
* `atomic_max`
* `atomic_min`
* `atomic_umax`
* `atomic_umin`

However, none of those functions and macros actually depend on 8-bit
width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit
etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we
would enable atomic CAS for it).

This change fixes that by removing the `"8"` argument from annotations,
which results in accepting the whole variety of widths.

Fixes rust-lang#106845
Fixes rust-lang#106795

Signed-off-by: Michal Rostecki <[email protected]>
This function didn't do what the authors intended it to do.

- Due to `move` in the closure `is_public` wasn't captured by mutalbe reference and wasn't used as a cache.
- Due to iterator cloning all the `should_encode_attr` logic run for the second time to calculate `may_have_doc_links`

This PR fixes these issues, and calculates all the needed attribute flags in one go.
Use `LocalDefId`s instead
The old way would compress okay with DEFLATE, but this version makes
uncompressed docs smaller, which matters for memory usage and stuff
like `cargo doc`.

Try it out: <https://play.rust-lang.org/?code=fn+main()+{%0Alet+mut+v+=+Vec::new();%0Av.push(1+/+1);%0Aprintln!(%22{}%22,+v[0]);%0A}>

In local testing, this change shrinks sample pages by anywhere between
4.0% and 0.031%

    $ du -b after.dir/std/vec/struct.Vec.html before.dir/std/vec/struct.Vec.html
    759235  after.dir/std/vec/struct.Vec.html
    781842  before.dir/std/vec/struct.Vec.html

100*((759235-781842)/781842)=-2.8

    $ du -b after.dir/std/num/struct.Wrapping.html before.dir/std/num/struct.Wrapping.html
    3194173 after.dir/std/num/struct.Wrapping.html
    3204351 before.dir/std/num/struct.Wrapping.html

100*((3194173-3204351)/3204351)=-0.031

    $ du -b after.dir/std/keyword.match.html before.dir/std/keyword.match.html
    8151    after.dir/std/keyword.match.html
    8495    before.dir/std/keyword.match.html

100*((8151-8495)/8495)=-4.0

Gzipped tarball sizes seem shrunk, but not by much.

    du -s before.tar.gz after.tar.gz
    69600   before.tar.gz
    69480   after.tar.gz

100*((69480-69600)/69600)=-0.17
update stdarch

This will allow using miri on simd instructions
rust-lang/stdarch#1347 (comment)
… r=joshtriplett

core: Support variety of atomic widths in width-agnostic functions

Before this change, the following functions and macros were annotated with `#[cfg(target_has_atomic = "8")]` or
`#[cfg(target_has_atomic_load_store = "8")]`:

* `atomic_int`
* `strongest_failure_ordering`
* `atomic_swap`
* `atomic_add`
* `atomic_sub`
* `atomic_compare_exchange`
* `atomic_compare_exchange_weak`
* `atomic_and`
* `atomic_nand`
* `atomic_or`
* `atomic_xor`
* `atomic_max`
* `atomic_min`
* `atomic_umax`
* `atomic_umin`

However, none of those functions and macros actually depend on 8-bit width and they are needed for all atomic widths (16-bit, 32-bit, 64-bit etc.). Some targets might not support 8-bit atomics (i.e. BPF, if we would enable atomic CAS for it).

This change fixes that by removing the `"8"` argument from annotations, which results in accepting the whole variety of widths.

Fixes rust-lang#106845
Fixes rust-lang#106795

Signed-off-by: Michal Rostecki <[email protected]>
rustc_metadata: Fix `encode_attrs`

This function didn't do what the authors intended it to do.

- Due to `move` in the closure `is_public` wasn't captured by mutalbe reference and wasn't used as a cache.
- Due to iterator cloning all the `should_encode_attr` logic run for the second time to calculate `may_have_doc_links`

This PR fixes these issues, and calculates all the needed attribute flags in one go.

(Noticed while implementing rust-lang#107136.)
…, r=GuillaumeGomez

rustdoc: make item links consistently use `title="{shortty} {path}"`

The ordering in item tables was flipped in 3030cbe, making it inconsistent with the ordering in method signatures.

Compare these (before this PR is merged):

https://github.com/rust-lang/rust/blob/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/src/librustdoc/html/render/print_item.rs#L455-L459

https://github.com/rust-lang/rust/blob/c8e6a9e8b6251bbc8276cb78cabe1998deecbed7/src/librustdoc/html/format.rs#L903-L908
…e, r=lcnr

Use new solver during selection

r? ``@lcnr``
rustdoc: use smarter encoding for playground URL

The old way would compress okay with DEFLATE, but this version makes uncompressed docs smaller, which matters for memory usage and stuff like `cargo doc`.

Try it out: <https://play.rust-lang.org/?code=fn+main()+{%0Alet+mut+v+=+Vec::new();%0Av.push(1+/+1);%0Aprintln!(%22{}%22,+v[0]);%0A}>

In local testing, this change shrinks sample pages by anywhere between 4.0% and 0.031%

    $ du -b after.dir/std/vec/struct.Vec.html before.dir/std/vec/struct.Vec.html
    759235  after.dir/std/vec/struct.Vec.html
    781842  before.dir/std/vec/struct.Vec.html

100*((759235-781842)/781842)=-2.8

    $ du -b after.dir/std/num/struct.Wrapping.html before.dir/std/num/struct.Wrapping.html
    3194173 after.dir/std/num/struct.Wrapping.html
    3204351 before.dir/std/num/struct.Wrapping.html

100*((3194173-3204351)/3204351)=-0.031

    $ du -b after.dir/std/keyword.match.html before.dir/std/keyword.match.html
    8151    after.dir/std/keyword.match.html
    8495    before.dir/std/keyword.match.html

100*((8151-8495)/8495)=-4.0

Gzipped tarball sizes seem shrunk, but not by much.

    du -s before.tar.gz after.tar.gz
    69600   before.tar.gz
    69480   after.tar.gz

100*((69480-69600)/69600)=-0.17
…omez

rustdoc: Stop using `HirId`s

Use `LocalDefId`s instead.
Rustdoc doesn't work with item bodies, so it almost never needs fine-grained HIR IDs.
…dule-item, r=GuillaumeGomez

rustdoc: remove mostly-unused CSS classes `import-item` and `module-item`
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jan 27, 2023
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=8

@bors
Copy link
Contributor

bors commented Jan 27, 2023

📌 Commit 17a2e1f has been approved by JohnTitor

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 27, 2023
@bors
Copy link
Contributor

bors commented Jan 27, 2023

⌛ Testing commit 17a2e1f with merge 18890f0...

@bors
Copy link
Contributor

bors commented Jan 27, 2023

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 18890f0 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jan 27, 2023
@bors bors merged commit 18890f0 into rust-lang:master Jan 27, 2023
@rustbot rustbot added this to the 1.69.0 milestone Jan 27, 2023
@rust-timer
Copy link
Collaborator

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (18890f0): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

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
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.7% [0.5%, 0.8%] 7
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.4% [-0.4%, -0.4%] 1
All ❌✅ (primary) 0.7% [0.5%, 0.8%] 7

Max RSS (memory usage)

Results

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.

mean range count
Regressions ❌
(primary)
2.9% [2.9%, 2.9%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-2.0% [-2.0%, -2.0%] 1
All ❌✅ (primary) 2.9% [2.9%, 2.9%] 1

Cycles

Results

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.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.7% [1.7%, 1.7%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

@rustbot rustbot added the perf-regression Performance regression. label Jan 27, 2023
@JohnTitor JohnTitor deleted the rollup-s6l94aj branch January 27, 2023 10:20
@Mark-Simulacrum Mark-Simulacrum added the perf-regression-triaged The performance regression has been triaged. label Jan 31, 2023
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. T-rustdoc Relevant to the rustdoc 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