Fix mod_inv termination for the last iteration #103378
Merged
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
rustbot
added
the
T-libs
|
r? @scottmcm (rust-highfive has picked a reviewer for you, use r? to override) |
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
rust-highfive
added
the
S-waiting-on-review
nagisa
force-pushed
the
fix-infinite-offset
branch
from
33bd8c1
to
d8fcdfd
Compare
This comment has been minimized.
This comment has been minimized.
On usize=u64 platforms, the 4th iteration would overflow the `mod_gate` back to 0. Similarly for usize=u32 platforms, the 3rd iteration would overflow much the same way. I tested various approaches to resolving this, including approaches with `saturating_mul` and `widening_mul` to a double usize. Turns out LLVM likes `mul_with_overflow` the best. In fact now, that LLVM can see the iteration count is limited, it will happily unroll the loop into a nice linear sequence. You will also notice that the code around the loop got simplified somewhat. Now that LLVM is handling the loop nicely, there isn’t any more reasons to manually unroll the first iteration out of the loop (though looking at the code today I’m not sure all that complexity was necessary in the first place). Fixes rust-lang#103361
nagisa
force-pushed
the
fix-infinite-offset
branch
from
d8fcdfd
to
a3c3f72
Compare
scottmcm
reviewed
Nov 15, 2022
|
|
||
| let table_inverse = INV_TABLE_MOD_16[(x & (INV_TABLE_MOD - 1)) >> 1] as usize; | ||
| // SAFETY: `m` is required to be a power-of-two, hence non-zero. | ||
| let m_minus_one = unsafe { unchecked_sub(m, 1) }; |
There was a problem hiding this comment.
Sadly unchecked is useless here today -- LLVM turns sub nuw %m, 1 into add %m, -1 during normalization :(
(Doesn't need to change here, though. I'm just sad about llvm/llvm-project#53377.)
|
Thanks! Really nice to hear that LLVM is smart enough to realize that this lets LLVM fully unroll it. @bors r+ |
bors
added
S-waiting-on-bors
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Nov 16, 2022
…tmcm Fix mod_inv termination for the last iteration On usize=u64 platforms, the 4th iteration would overflow the `mod_gate` back to 0. Similarly for usize=u32 platforms, the 3rd iteration would overflow much the same way. I tested various approaches to resolving this, including approaches with `saturating_mul` and `widening_mul` to a double usize. Turns out LLVM likes `mul_with_overflow` the best. In fact now, that LLVM can see the iteration count is limited, it will happily unroll the loop into a nice linear sequence. You will also notice that the code around the loop got simplified somewhat. Now that LLVM is handling the loop nicely, there isn’t any more reasons to manually unroll the first iteration out of the loop (though looking at the code today I’m not sure all that complexity was necessary in the first place). Fixes rust-lang#103361
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 18, 2022
…earth Rollup of 8 pull requests Successful merges: - rust-lang#102977 (remove HRTB from `[T]::is_sorted_by{,_key}`) - rust-lang#103378 (Fix mod_inv termination for the last iteration) - rust-lang#103456 (`unchecked_{shl|shr}` should use `u32` as the RHS) - rust-lang#103701 (Simplify some pointer method implementations) - rust-lang#104047 (Diagnostics `icu4x` based list formatting.) - rust-lang#104338 (Enforce that `dyn*` coercions are actually pointer-sized) - rust-lang#104498 (Edit docs for `rustc_errors::Handler::stash_diagnostic`) - rust-lang#104556 (rustdoc: use `code-header` class to format enum variants) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
RalfJung
reviewed
Nov 20, 2022
| #[cfg(target_pointer_width = "16")] | ||
| const SIZE: usize = 1 << 13; | ||
| struct HugeSize([u8; SIZE - 1]); | ||
| let _ = (SIZE as *const HugeSize).align_offset(SIZE); |
There was a problem hiding this comment.
We usually prefer the strict provenance APIs in libcore -- #104632
Note sure if the lint against int2ptr casts ever got implemented? If yes we should probably enable it here.
There was a problem hiding this comment.
Ah, I basically just copy-pasted over the reproducer from the issue…
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.
On usize=u64 platforms, the 4th iteration would overflow the
mod_gateback to 0. Similarly for usize=u32 platforms, the 3rd iteration would overflow much the same way.I tested various approaches to resolving this, including approaches with
saturating_mulandwidening_multo a double usize. Turns out LLVM likesmul_with_overflowthe best. In fact now, that LLVM can see the iteration count is limited, it will happily unroll the loop into a nice linear sequence.You will also notice that the code around the loop got simplified somewhat. Now that LLVM is handling the loop nicely, there isn’t any more reasons to manually unroll the first iteration out of the loop (though looking at the code today I’m not sure all that complexity was necessary in the first place).
Fixes #103361