Rollup of 7 pull requests #84757
Closed
Rollup of 7 pull requests #84757
Conversation
This file contains 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
…location function
Split into five sections to match the tiers: "Tier 1 with Host Tools", "Tier 1", "Tier 2 with Host Tools", "Tier 2", and "Tier 3". Explain each tier briefly in prose, and link to the corresponding section of the policy for full requirements. Drop the `host` columns from the first four, since the different sections distinguish that. (Keep the `host` column for "Tier 3", since it's a single list and the `host` column just indicates if host tools are expected to work.) Targets with host tools always have full support for std, so drop the `std` column from those. Move the explanations of the `std` column next to the appropriate tables, and drop the unknown/WIP case for tier 2 targets. Use "target" terminology consistently throughout. Sort each table by target name.
On arm64 we have seen on several databases that ISB (instruction synchronization barrier) is better to use than yield in a spin loop. The yield instruction is a nop. The isb instruction puts the processor to sleep for some short time. isb is a good equivalent to the pause instruction on x86. Below is an experiment that shows the effects of yield and isb on Arm64 and the time of a pause instruction on x86 Intel processors. The micro-benchmarks use https://github.com/google/benchmark.git $ cat a.cc static void BM_scalar_increment(benchmark::State& state) { int i = 0; for (auto _ : state) benchmark::DoNotOptimize(i++); } BENCHMARK(BM_scalar_increment); static void BM_yield(benchmark::State& state) { for (auto _ : state) asm volatile("yield"::); } BENCHMARK(BM_yield); static void BM_isb(benchmark::State& state) { for (auto _ : state) asm volatile("isb"::); } BENCHMARK(BM_isb); BENCHMARK_MAIN(); $ g++ -o run a.cc -O2 -lbenchmark -lpthread $ ./run -------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------- AWS Graviton2 (Neoverse-N1) processor: BM_scalar_increment 0.485 ns 0.485 ns 1000000000 BM_yield 0.400 ns 0.400 ns 1000000000 BM_isb 13.2 ns 13.2 ns 52993304 AWS Graviton (A-72) processor: BM_scalar_increment 0.897 ns 0.874 ns 801558633 BM_yield 0.877 ns 0.875 ns 800002377 BM_isb 13.0 ns 12.7 ns 55169412 Apple Arm64 M1 processor: BM_scalar_increment 0.315 ns 0.315 ns 1000000000 BM_yield 0.313 ns 0.313 ns 1000000000 BM_isb 9.06 ns 9.06 ns 77259282 static void BM_pause(benchmark::State& state) { for (auto _ : state) asm volatile("pause"::); } BENCHMARK(BM_pause); Intel Skylake processor: BM_scalar_increment 0.295 ns 0.295 ns 1000000000 BM_pause 41.7 ns 41.7 ns 16780553 Tested on Graviton2 aarch64-linux with `./x.py test`.
…xtern_locations, r=jyn514 rustdoc: Only store locations in Cache::extern_locations and calculate the other info on-demand help rust-lang#84588
…ulacrum Unignore a couple of tests
…t-tier-policy, r=pietroalbini platform-support.md: Update for consistency with Target Tier Policy Split into five sections to match the tiers: "Tier 1 with Host Tools", "Tier 1", "Tier 2 with Host Tools", "Tier 2", and "Tier 3". Explain each tier briefly in prose, and link to the corresponding section of the policy for full requirements. Drop the `host` columns from the first four, since the different sections distinguish that. (Keep the `host` column for "Tier 3", since it's a single list and the `host` column just indicates if host tools are expected to work.) Targets with host tools always have full support for std, so drop the `std` column from those. Move the explanations of the `std` column next to the appropriate tables, and drop the unknown/WIP case for tier 2 targets. Use "target" terminology consistently throughout. Sort each table by target name.
[Arm64] use isb instruction instead of yield in spin loops On arm64 we have seen on several databases that ISB (instruction synchronization barrier) is better to use than yield in a spin loop. The yield instruction is a nop. The isb instruction puts the processor to sleep for some short time. isb is a good equivalent to the pause instruction on x86. Below is an experiment that shows the effects of yield and isb on Arm64 and the time of a pause instruction on x86 Intel processors. The micro-benchmarks use https://github.com/google/benchmark.git ``` $ cat a.cc static void BM_scalar_increment(benchmark::State& state) { int i = 0; for (auto _ : state) benchmark::DoNotOptimize(i++); } BENCHMARK(BM_scalar_increment); static void BM_yield(benchmark::State& state) { for (auto _ : state) asm volatile("yield"::); } BENCHMARK(BM_yield); static void BM_isb(benchmark::State& state) { for (auto _ : state) asm volatile("isb"::); } BENCHMARK(BM_isb); BENCHMARK_MAIN(); $ g++ -o run a.cc -O2 -lbenchmark -lpthread $ ./run -------------------------------------------------------------- Benchmark Time CPU Iterations -------------------------------------------------------------- AWS Graviton2 (Neoverse-N1) processor: BM_scalar_increment 0.485 ns 0.485 ns 1000000000 BM_yield 0.400 ns 0.400 ns 1000000000 BM_isb 13.2 ns 13.2 ns 52993304 AWS Graviton (A-72) processor: BM_scalar_increment 0.897 ns 0.874 ns 801558633 BM_yield 0.877 ns 0.875 ns 800002377 BM_isb 13.0 ns 12.7 ns 55169412 Apple Arm64 M1 processor: BM_scalar_increment 0.315 ns 0.315 ns 1000000000 BM_yield 0.313 ns 0.313 ns 1000000000 BM_isb 9.06 ns 9.06 ns 77259282 ``` ``` static void BM_pause(benchmark::State& state) { for (auto _ : state) asm volatile("pause"::); } BENCHMARK(BM_pause); Intel Skylake processor: BM_scalar_increment 0.295 ns 0.295 ns 1000000000 BM_pause 41.7 ns 41.7 ns 16780553 ``` Tested on Graviton2 aarch64-linux with `./x.py test`.
Reset the docs' copy path button after 1 second I like that this copy path button on the top next to the type/module's name changes to a check mark when you successfully clicked and copied the path but I find it really weird how the icon stays that check mark forever after the first time of clicking it. Imagine you leave that documentation tab open and come back after 2 hours and you still see that check mark in that box because you copied the path 2 hours ago. You will probably be confused and you might've forgotten what that button even does (even more so currently where this is a new feature, or when you simply don't use it often), so I really think at some point it should go back to the ⎘ icon which, at least to me, pretty clearly indicates copying, whereas the check mark (if it stays there for so long) could falsely look like a verification mark indicating "this module is verified" or something like that. I believe after a longer period of time it's not logical to still tell the user "yes you've copied this successful". In addition to this timeout, maybe it could be made so that you can't copy again until this cooldown of 1 second is over, but I'm not sure how useful or user-friendly that feature would be so maybe it's fine the way it is now. Also the timeout is cleared every time you click again so if you constantly click it, it won't reset during that.
Update Miri To include rust-lang/miri#1783, hence fixes rust-lang#84741. r? `@RalfJung`
…aumeGomez Add a ToC to the Target Tier Policy documentation The policy document is quite lengthy, I figured it might be good to have a quick way to jump to the specific tier policies.
|
@bors: r+ p=7 rollup=never |
|
📌 Commit 4511013 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 4511013 with merge c44df0d80b64a7e06cce55257bdeba552fd02c37... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
I don't have access to the failure logs apparently. Does someone from the @rust-lang/infra have access to it? Closing the rollup PR in the meantime. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup