Optimize ToString implementation for integers

[GuillaumeGomez]

Part of #135543.

Follow-up of #133247 and #128204.

The benchmark results are:

name	1.87.0-nightly (3ea711f 2025-03-09)	With this PR	diff
bench_i16	32.06 ns/iter (+/- 0.12)	17.62 ns/iter (+/- 0.03)	-45%
bench_i32	31.61 ns/iter (+/- 0.04)	15.10 ns/iter (+/- 0.06)	-52%
bench_i64	31.71 ns/iter (+/- 0.07)	15.02 ns/iter (+/- 0.20)	-52%
bench_i8	13.21 ns/iter (+/- 0.14)	14.93 ns/iter (+/- 0.16)	+13%
bench_u16	31.20 ns/iter (+/- 0.06)	16.14 ns/iter (+/- 0.11)	-48%
bench_u32	33.27 ns/iter (+/- 0.05)	16.18 ns/iter (+/- 0.10)	-51%
bench_u64	31.44 ns/iter (+/- 0.06)	16.62 ns/iter (+/- 0.21)	-47%
bench_u8	10.57 ns/iter (+/- 0.30)	13.00 ns/iter (+/- 0.43)	+22%

More information about it in the original comment.

r? @workingjubilee

[rustbot]

Could not assign reviewer from: workingjubilee.
User(s) workingjubilee are either the PR author, already assigned, or on vacation. Please use r? to specify someone else to assign.

[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

[GuillaumeGomez]

I'm very confused by the CI errors. Did I unfold a very weird bug somehow? Like 0 != 0. 😮

[workingjubilee]

specialization strikes again, perhaps

[theemathas]

It seems to me that the tests are testing for a known miscompilation: #107975

[theemathas]

I'm guessing that this PR caused the compiler to be able to figure out that calling to_string on a number doesn't cause that number to change, allowing more optimizations to happen, causing the miscompilation to behave differently.

[workingjubilee]

lovely.

[GuillaumeGomez]

Fixed CI. So now about benching the change: any suggestion @workingjubilee ?

In the meantime:

@bors try @rust-timer queue

[bors]

⌛ Trying commit 83dc76e with merge 97c5b4b...

[bors]

☀️ Try build successful - checks-actions
Build commit: 97c5b4b (97c5b4b9bc9a34c7dde8738389ba12cb733cd54e)

[rust-timer]

Finished benchmarking commit (97c5b4b): comparison URL.

Overall result: ✅ improvements - no action needed

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 may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.6%, -0.1%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.4%	[-0.6%, -0.1%]	2

Max RSS (memory usage)

Results (primary 0.3%, secondary 2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.2%	[3.2%, 3.2%]	1
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-2.6%	[-2.6%, -2.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-2.6%, 3.2%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.1%, secondary 0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 1.0%]	22
Regressions ❌ (secondary)	0.5%	[0.5%, 0.5%]	3
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.0%]	6
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	3
All ❌✅ (primary)	0.1%	[-0.2%, 1.0%]	28

Bootstrap: 776.287s -> 777.396s (0.14%)
Artifact size: 328.44 MiB -> 328.53 MiB (0.03%)

[workingjubilee]

I don't believe the tests should be changed in this way.

[GuillaumeGomez]

I'm not sure if we should keep the code and modify it (like I did) or just comment out the parts that are failing. Or maybe you see a third way?

[workingjubilee]

The point of these tests is the series of asserts, changing just one line or two that fails undermines the point.

[GuillaumeGomez]

The point was testing that calling to_string on them somehow changed the value. The new checks ensure that it doesn't and I commented as such. Not too sure what else to do on them.

[workingjubilee]

These are known-bug tests.

They are testing for the existence of a bug.

We did not fix the bug, because there are other ways to reach the compilation quirks in question. They have little to nothing to do with to_string in particular. We changed the code it was testing from under its feet, so the test has to be different code in order to still be a useful test, as what we want is to verify when LLVM stops miscompiling a sequence of LLVMIR.

[GuillaumeGomez]

Oh I see. So in short, calling any method on the type should still trigger the original bug iiuc. Let me give it a try. In the meantime, any idea on how to bench this PR?

[GuillaumeGomez]

You were right, just calling another method did the trick. Tests are now back to what they were.

[workingjubilee]

Thank you. I will think about that a bit.

[bors]

☔ The latest upstream changes (presumably #135265) made this pull request unmergeable. Please resolve the merge conflicts.

[GuillaumeGomez]

Fixed the feature reason.

[Amanieu]

Considering #138338 is likely to re-use much of this code, I'm much less concerned about the testing.

@bors r+

[bors]

📌 Commit 1ef7585 has been approved by Amanieu

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1ef7585 with merge ea6a345...

[bors]

💔 Test failed - checks-actions

[GuillaumeGomez]

I don't see any failure in the logs, weird. Let's retry...

@bors retry

[bors]

⌛ Testing commit 1ef7585 with merge 4f45c38...

[jnkr-ifx]

Seems like the runner might have run out of disk space, and failed to write the logs because of that?

[GuillaumeGomez]

I see, thanks for the info! 😅

[rust-log-analyzer]

The job x86_64-msvc-1 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

test [rustdoc] tests\rustdoc\private\private-use.rs ... FAILED
test [rustdoc] tests\rustdoc\private\public-impl-mention-private-generic-46380-2.rs ... FAILED
test [rustdoc] tests\rustdoc\private\traits-in-bodies-private.rs ... FAILED
test [rustdoc] tests\rustdoc\process-termination.rs ... FAILED
##[error]There is not enough space on the disk. : 'C:\actions-runner\cached\_diag\blocks\4f981a31-0bbb-4f3c-8b05-9965fa65a308_39055c4c-82f8-4ffa-8080-4a9fd1e87263.2'
##[error]There is not enough space on the disk. : 'C:\actions-runner\cached\_diag\pages\4f981a31-0bbb-4f3c-8b05-9965fa65a308_7b77d366-83b8-417e-a213-7cf4e4d63b93_1.log'

[bors]

💔 Test failed - checks-actions

[GuillaumeGomez]

@rust-lang/infra Not sure what's going on here. Seems to not have enough disk space anymore in CI?

[marcoieni]

Ooops, yes. I'll try to raise a PR to save some space by removing useless tools.
In the meantime you can switch to the runner job-windows-25-8c.