allow large Size again #95456
allow large Size again #95456
Conversation
rustbot
added
the
T-compiler
rust-highfive
added
the
S-waiting-on-review
|
I think this should be perf-neutral but let's see. |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit 2799885 with merge db69c0f1fa2b71d1412a833d4b3c189e1520d38d... |
|
☀️ Try build successful - checks-actions |
|
Queued db69c0f1fa2b71d1412a833d4b3c189e1520d38d with parent 9c06e1b, future comparison URL. |
|
Finished benchmarking commit (db69c0f1fa2b71d1412a833d4b3c189e1520d38d): comparison url. Summary: This benchmark run did not return any relevant results. 5 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
rustbot
removed
the
S-waiting-on-perf
|
@bors r+ |
|
📌 Commit 2799885 has been approved by |
bors
added
S-waiting-on-bors
allow large Size again This basically reverts most of rust-lang#80042, and instead does the panic in `bits()` with a `#[cold]` function to make sure it does not get inlined. rust-lang#80042 added a comment about an invariant ("The top 3 bits are ALWAYS zero") that is not actually enforced, and if it were enforced that would be a problem for rust-lang#95388. So I think we should not have that invariant, and I adjusted the code accordingly. r? `@oli-obk` Cc `@sivadeilra`
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (df20355): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
This basically reverts most of #80042, and instead does the panic in
bits()with a#[cold]function to make sure it does not get inlined.#80042 added a comment about an invariant ("The top 3 bits are ALWAYS zero") that is not actually enforced, and if it were enforced that would be a problem for #95388. So I think we should not have that invariant, and I adjusted the code accordingly.
r? @oli-obk Cc @sivadeilra