a3c3f722b7
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 #103361 |
||
---|---|---|
.. | ||
fmt | ||
hash | ||
iter | ||
num | ||
ops | ||
panic | ||
alloc.rs | ||
any.rs | ||
array.rs | ||
ascii.rs | ||
asserting.rs | ||
atomic.rs | ||
bool.rs | ||
cell.rs | ||
char.rs | ||
clone.rs | ||
cmp.rs | ||
const_ptr.rs | ||
convert.rs | ||
future.rs | ||
intrinsics.rs | ||
lazy.rs | ||
lib.rs | ||
macros.rs | ||
manually_drop.rs | ||
mem.rs | ||
nonzero.rs | ||
ops.rs | ||
option.rs | ||
panic.rs | ||
pattern.rs | ||
pin_macro.rs | ||
pin.rs | ||
ptr.rs | ||
result.rs | ||
simd.rs | ||
slice.rs | ||
str_lossy.rs | ||
str.rs | ||
task.rs | ||
time.rs | ||
tuple.rs | ||
unicode.rs | ||
waker.rs |