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

Forward Hash::write_iN to Hash::write_uN #73800

Merged
merged 1 commit into from
Jun 28, 2020
Merged

Conversation

nikic
Copy link
Contributor

@nikic nikic commented Jun 27, 2020

The Hasher::write_iN() methods should forward to Hasher::write_uN(), because some Hasher implementations implement only the write_uN() variants, with the expectation that write_iN() will use the same implementation. Most notably, this is the case for the FxHasher used by rustc itself.

This used to be the case previously, but was broken in #59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from #73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of FxHasher::write() getting inlined to get reasonable performance.

@rust-highfive
Copy link
Collaborator

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 27, 2020
@kennytm
Copy link
Member

kennytm commented Jun 28, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Jun 28, 2020

📌 Commit 4c14f9d has been approved by kennytm

@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 Jun 28, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Jun 28, 2020
Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
@Mark-Simulacrum
Copy link
Member

@bors retry rollup=never

May have perf implications

Manishearth added a commit to Manishearth/rust that referenced this pull request Jun 28, 2020
Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jun 28, 2020
…arth

Rollup of 9 pull requests

Successful merges:

 - rust-lang#73577 (Add partition_point)
 - rust-lang#73757 (Const prop: erase all block-only locals at the end of every block)
 - rust-lang#73774 (Make liveness more precise for assignments to fields)
 - rust-lang#73795 (Add some `const_compare_raw_pointers`-related regression tests)
 - rust-lang#73800 (Forward Hash::write_iN to Hash::write_uN)
 - rust-lang#73813 (Rename two `Resolver` traits)
 - rust-lang#73817 (Rename clashing_extern_decl to clashing_extern_declarations.)
 - rust-lang#73826 (Fix docstring typo)
 - rust-lang#73833 (Remove GlobalCtxt::enter_local)

Failed merges:

r? @ghost
@nagisa
Copy link
Member

nagisa commented Jun 28, 2020

May I think may have observable change in behaviour, not sure if that means this PR is acceptable or not...

@cuviper
Copy link
Member

cuviper commented Jun 28, 2020

In that sense, this is just reverting the observable change in #59982.

@nagisa
Copy link
Member

nagisa commented Jun 28, 2020

In that sense, this is just reverting the observable change in #59982.

Not really. It was a change from

         self.write(&unsafe { mem::transmute::<_, [u8; 4]>(i) }) 

to

        self.write(&i.to_ne_bytes())

In both cases the function called, the data types, and the values supplied were identical. A Hasher::write(&[...]) may result in a different hash value compared to calling Hasher::write_u32 with the same bytes, as the Hasher has liberty to implement hashing of the two differently.

@nagisa
Copy link
Member

nagisa commented Jun 28, 2020

Oh sorry, I see what you mean, I was looking at the wrong functions ^^ Ignore me.

@bors bors merged commit 95da53f into rust-lang:master Jun 28, 2020
@nikic nikic mentioned this pull request Jun 29, 2020
@cuviper
Copy link
Member

cuviper commented Jun 29, 2020

rollup=never ... May have perf implications

It was accidentally rolled up anyway in #73838.
FWIW, here's the perf comparison of that rollup as a whole.

@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants