Rollup of 8 pull requests #69094
Merged
Rollup of 8 pull requests #69094
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
The current code in `SipHasher128::short_write` is inefficient. It uses `u8to64_le` (which is complex and slow) to extract just the right number of bytes of the input into a u64 and pad the result with zeroes. It then left-shifts that value in order to bitwise-OR it with `self.tail`. For example, imagine we have a u32 input 0xIIHH_GGFF and only need three bytes to fill up `self.tail`. The current code uses `u8to64_le` to construct 0x0000_0000_00HH_GGFF, which is just 0xIIHH_GGFF with the 0xII removed and zero-extended to a u64. The code then left-shifts that value by five bytes -- discarding the 0x00 byte that replaced the 0xII byte! -- to give 0xHHGG_FF00_0000_0000. It then then ORs that value with self.tail. There's a much simpler way to do it: zero-extend to u64 first, then left shift. E.g. 0xIIHH_GGFF is zero-extended to 0x0000_0000_IIHH_GGFF, and then left-shifted to 0xHHGG_FF00_0000_0000. We don't have to take time to exclude the unneeded 0xII byte, because it just gets shifted out anyway! It also avoids multiple occurrences of `unsafe`. There's a similar story with the setting of `self.tail` at the method's end. The current code uses `u8to64_le` to extract the remaining part of the input, but the same effect can be achieved more quickly with a right shift on the zero-extended input. All that works on little-endian. It doesn't work for big-endian, but we can just do a `to_le` before calling `short_write` and then it works. This commit changes `SipHasher128` to use the simpler shift-based approach. The code is also smaller, which means that `short_write` is now inlined where previously it wasn't, which makes things faster again. This gives big speed-ups for all incremental builds, especially "baseline" incremental builds.
Allows parallel install of different rust channels Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
These methods explicitly check if a char is in a specific ASCII range, therefore the `is_ascii()` check is not needed, but LLVM seems to be unable to remove it. WARNING: this change improves the performance on ASCII `char`s, but complex checks such as `is_ascii_punctuation` become slower on non-ASCII `char`s.
This makes it faster and also changes it to a safe function. (Thanks to Michael Woerister for the suggestion.) `load_int_le!` is also no longer necessary.
…r=Amanieu Improve `char::is_ascii_*` codegen This PR is an attempt to fix rust-lang#65127 A couple of warnings: 1. the generated code might be further improved (in LLVM and/or MIR) by emitting better comparison sequences; in particular, this would improve the performance of "complex" checks such as those in `is_ascii_punctuation` 2. the second commit is currently marked "DO NOT MERGE", because it regresses SIMD on `u8` slices; this could likely be fixed by improving the computation/usage of demanded bits in LLVM An alternative approach to remove the code duplication might be the use of macros, but currently most of the duplication is actually in the doc comments, so maybe just keeping the redundancy could be ok
…r=michaelwoerister Speed up `SipHasher128`. The current code in `SipHasher128::short_write` is inefficient. It uses `u8to64_le` (which is complex and slow) to extract just the right number of bytes of the input into a u64 and pad the result with zeroes. It then left-shifts that value in order to bitwise-OR it with `self.tail`. For example, imagine we have a u32 input `0xIIHH_GGFF` and only need three bytes to fill up `self.tail`. The current code uses `u8to64_le` to construct `0x0000_0000_00HH_GGFF`, which is just `0xIIHH_GGFF` with the `0xII` removed and zero-extended to a u64. The code then left-shifts that value by five bytes -- discarding the `0x00` byte that replaced the `0xII` byte! -- to give `0xHHGG_FF00_0000_0000`. It then then ORs that value with `self.tail`. There's a much simpler way to do it: zero-extend to u64 first, then left shift. E.g. `0xIIHH_GGFF` is zero-extended to `0x0000_0000_IIHH_GGFF`, and then left-shifted to `0xHHGG_FF00_0000_0000`. We don't have to take time to exclude the unneeded `0xII` byte, because it just gets shifted out anyway! It also avoids multiple occurrences of `unsafe`. There's a similar story with the setting of `self.tail` at the method's end. The current code uses `u8to64_le` to extract the remaining part of the input, but the same effect can be achieved more quickly with a right shift on the zero-extended input. This commit changes `SipHasher128` to use the simpler shift-based approach. The code is also smaller, which means that `short_write` is now inlined where previously it wasn't, which makes things faster again. This gives big speed-ups for all incremental builds, especially "baseline" incremental builds. r? @michaelwoerister
…-Simulacrum rustbuild: include channel in sanitizers installed name Allows parallel install of different rust channels. I'm not sure if the channel is the right thing to use there, but currently both beta and nightly try to install e.g. `/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_rt.asan.a` when before (and in current stable) it used to be `/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_asan-45a4390180e83d28.rlib` which contained a hash, making it unique. With this patch, `/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-nightly_rt.asan.a` gets installed
…t-lang#69017, r=petrochenkov ICE in nightly-2020-02-08: handle TerminatorKind::Yield in librustc_mir::transform::promote_consts::Validator method IR: rust-lang#69017 regressed commit: rust-lang@f8fd462 Source: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=55e65a869e1f5fef64cc4462b1a5a087 Addresses ICE reported in rust-lang#69017 by handling `TerminatorKind::Yield` in https://github.com/rust-lang/rust/blob/4d1241f5158ffd66730e094d8f199ed654ed52ae/src/librustc_mir/transform/promote_consts.rs#L465-L468. <details><summary>Nightly build</summary> <p> ``` $ cargo +nightly build Compiling yielder v0.1.0 (/Users/chris/Desktop/tests/rustlang-tests/yielder) error: internal compiler error: src/librustc_mir/transform/promote_consts.rs:467: _1 = suspend(move _21) -> [resume: bb2, drop: bb3] not promotable --> src/main.rs:8:27 | 8 | println!("-> {}", yield); | ^^^^^ thread 'rustc' panicked at 'Box<Any>', <::std::macros::panic macros>:2:4 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports note: rustc 1.43.0-nightly (71c7e14 2020-02-09) running on x86_64-apple-darwin note: compiler flags: -C debuginfo=2 -C incremental --crate-type bin note: some of the compiler flags provided by cargo are hidden error: aborting due to previous error error: could not compile `yielder`. To learn more, run the command again with --verbose. ``` </p> </details> <details><summary>Stage 1 dev build</summary> <p> ``` $ cargo +stage1 build Compiling yielder v0.1.0 (/Users/chris/Desktop/tests/rustlang-tests/yielder) warning: function is never used: `gen` --> src/main.rs:6:4 | 6 | fn gen() -> impl Generator<usize> { | ^^^ | = note: `#[warn(dead_code)]` on by default Finished dev [unoptimized + debuginfo] target(s) in 0.53s ``` </p> </details> @jonas-schievink @oli-obk
parser: Remove `Parser::prev_token_kind` Follow-up to rust-lang#69006. r? @Centril
Remove backtrace header text Fixes point 3 from rust-lang#65280 related to rust-lang#53487 This should probably be double checked by someone who works on fuschia because theres some extra fuschia specific output in `add_context` that is also removed by this change.
Remove a few unused objects As far as I can tell, these won't be missed: - `infer::region_constraints::ConstraintInfo` - `driver::DefaultCallbacks` - ~~`hir::intravisit::ParDeepVisitor`~~
Properly use the darwin archive format on Apple targets See servo/servo#25550.
|
@bors r+ p=8 rollup=never |
|
📌 Commit d9982f1 has been approved by |
bors
added
the
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Feb 12, 2020
Rollup of 8 pull requests Successful merges: - #67585 (Improve `char::is_ascii_*` codegen) - #68914 (Speed up `SipHasher128`.) - #68994 (rustbuild: include channel in sanitizers installed name) - #69032 (ICE in nightly-2020-02-08: handle TerminatorKind::Yield in librustc_mir::transform::promote_consts::Validator method) - #69034 (parser: Remove `Parser::prev_token_kind`) - #69042 (Remove backtrace header text) - #69059 (Remove a few unused objects) - #69089 (Properly use the darwin archive format on Apple targets) Failed merges: r? @ghost
|
☀️ Test successful - checks-azure |
This was referenced Feb 12, 2020
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:
char::is_ascii_*codegen #67585 (Improvechar::is_ascii_*codegen)SipHasher128. #68914 (Speed upSipHasher128.)Parser::prev_token_kind#69034 (parser: RemoveParser::prev_token_kind)Failed merges:
r? @ghost