Add ilog10 result range hints

[EFanZh]

This PR adds hints that the return value of T::ilog10 will never exceed T::MAX.ilog10().

This works because ilog10 is a monotonically nondecreasing function, the maximum return value is reached at the max input value.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Noratrieb]

Is this motivated by concrete codegen improvements (the codegen tests are quite artificial)? assume/assert_unchecked always has the potential to go either way wrt performance, so it would be good to know whether you've confirmed that this improves real-world code

[jhorstmann]

Interesting that llvm can already infer some bounds, but apparently not the tightest ones. Looking at the following functions in compiler explorer, there are no panics:

pub fn test_u8(i: std::num::NonZeroU8, a: &[u32; 3]) -> u32 {
    a[i.ilog10() as usize]
}

pub fn test_u16(i: std::num::NonZeroU16, a: &[u32; 8]) -> u32 {
    a[i.ilog10() as usize]
}

pub fn test_u32(i: std::num::NonZeroU32, a: &[u32; 13]) -> u32 {
    a[i.ilog10() as usize]
}

pub fn test_u64(i: std::num::NonZeroU64, a: &[u32; 23]) -> u32 {
    a[i.ilog10() as usize]
}

These functions with tighter bounds would make for nicer codegen test.

[EFanZh]

@Noratrieb: An example would be getting a slice of digits of an integer where adding an assertion can remove bound checking code:

pub fn get_digits(mut x: u32, buffer: &mut [u8; 10]) -> &mut [u8] {
    let digits = &mut buffer[..x.checked_ilog10().unwrap_or_default() as usize + 1];

    for slot in &mut *digits {
        *slot = (x % 10) as u8;
        x /= 10;
    }

    digits
}

You can compare the the codegen results here.

Also, isqrt already have a similar assertion like this:

rust/library/core/src/num/uint_macros.rs

Lines 3373 to 3392 in 94b49fd

	pub const fn isqrt(self) -> Self {
	let result = crate::num::int_sqrt::$ActualT(self as $ActualT) as $SelfT;
	// Inform the optimizer what the range of outputs is. If testing
	// `core` crashes with no panic message and a `num::int_sqrt::u*`
	// test failed, it's because your edits caused these assertions or
	// the assertions in `fn isqrt` of `nonzero.rs` to become false.
	//
	// SAFETY: Integer square root is a monotonically nondecreasing
	// function, which means that increasing the input will never
	// cause the output to decrease. Thus, since the input for unsigned
	// integers is bounded by `[0, <$ActualT>::MAX]`, sqrt(n) will be
	// bounded by `[sqrt(0), sqrt(<$ActualT>::MAX)]`.
	unsafe {
	const MAX_RESULT: $SelfT = crate::num::int_sqrt::$ActualT(<$ActualT>::MAX) as $SelfT;
	crate::hint::assert_unchecked(result <= MAX_RESULT);
	}
	result
	}

I think it is reasonable that we do the same on ilog10, otherwise it is difficult to explain why is there behavior difference between isqrt and ilog10.

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[EFanZh]

@rustbot ready.

[Mark-Simulacrum]

Given the precedent with sqrt I'll go ahead and approve this. I checked and neither the compiler nor rustc-perf seems to have any meaningful use of ilog10 so our perf suite is probably not capable of determining negative compile-time impact (which is one of the tradeoffs here).

@bors r+

[bors]

📌 Commit 4046385 has been approved by Mark-Simulacrum

It is now in the queue for this repository.