Vectorize checked multiplication by reporting evidence, not a comparison

[connortsui20]

Replaces the per-lane overflow comparison in checked multiplication with the bits the narrow product discards. An unsigned checked multiply widens both operands, multiplies, and compares the product against the narrow maximum, and LLVM canonicalizes that into llvm.umul.with.overflow, which has no vector lowering. Eight spellings of the check compile to the same scalar code. The lane now returns the discarded half of the true product, which is non-zero on exactly the lanes that overflow, and map_checked_into OR-reduces it. Overflow detection is unchanged for every input.

The narrow signed widths keep their two-sided range check, which LLVM does not fold, so they measure neutral below. map_checked_into asserts that the evidence is no wider than the value, because a wider word puts the reduction rather than the arithmetic in charge of how many lanes a vector covers. The three kernel wrappers also relax from #[inline(always)] to #[inline], which measures the same.

Open question: do the 64-bit widths need u64 evidence rather than bool? There is no vector integer multiply at 64-bit width below AVX-512DQ, so the width is possibly not load-bearing on the CodSpeed runner.

Follow-up: prove from cached Stat::Min and Stat::Max that a multiply cannot overflow and skip the check entirely, the way values_fit_in already does for narrowing casts in cast.rs. Against a build with the check compiled out, that is worth a further 1.9x at u8 and nothing at u32.

Benchmark results

binary_ops, 65536 rows, divan fastest of 100 samples, interleaved A/B over two rounds against develop on an Apple M4 Max. add_i64_nonnull, div_i64_nonnull and eq_i64_constant are controls over untouched code.

benchmark	before	after
mul_u8_nonnull	10.74 µs	1.332 µs	8.1x
mul_u16_nonnull	11.58 µs	1.707 µs	6.8x
mul_u32_nonnull	12.29 µs	3.457 µs	3.6x
mul_u64_nonnull	12.41 µs	6.999 µs	1.8x
mul_i64_nonnull	13.20 µs	8.082 µs	1.6x
mul_i8_nonnull	1.457 µs	1.457 µs	neutral
mul_i16_nonnull	2.624 µs	2.624 µs	neutral
mul_i32_nonnull	3.957 µs	3.999 µs	neutral
mul_i32_nullable	4.540 µs	4.540 µs	neutral
mul_i32_constant	3.915 µs	3.957 µs	neutral
add_i64_nonnull	6.791 µs	6.832 µs	control
div_i64_nonnull	18.79 µs	17.54 µs	control
eq_i64_constant	3.582 µs	3.582 µs	control

mul.with.overflow falls from 20 occurrences to 4 across the checked kernels, and OR reductions appear at v16i8, v8i16 and v4i32, each the width of its own operand. The remaining 4 are the scalar constant-folding path.

CodSpeed runs on x86, where the 64-bit rows are expected to differ from the aarch64 numbers above.

[codspeed-hq]

Merging this PR will regress 1 benchmark

⚡ 3 improved benchmarks
❌ 1 regressed benchmark
✅ 1891 untouched benchmarks
⏩ 43 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	decompress[u64, (1000, 16)]	65.2 µs	73.7 µs	-11.5%
⚡	Simulation	mul_u8_nonnull	405.3 µs	165.8 µs	×2.4
⚡	Simulation	mul_u16_nonnull	501.5 µs	269.7 µs	+85.94%
⚡	Simulation	mul_u32_nonnull	722.3 µs	487.3 µs	+48.24%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ct/unsigned-mul-evidence (ec9c9b1) with develop (8316455)}

Footnotes

1. 43 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[robert3005]

this stands out quite a lot

[robert3005]

but I guess you only need this for multiplication since division won't work like this and add/sub only needs a bool