Delete architecture-specific memchr code in std::sys

[krtab]

Currently all architecture-specific memchr code is only used in std::io. Most of the actual memchr capacity exposed to the user through the slice API is instead implemented in core::slice::memchr.

Hence this commit deletes memchr from std::sys[_common] and replace calls to it by calls to core::slice::memchr functions. This deletes (r)memchr from the list of symbols linked to libc.

The interest of putting architecture specific code back in core is linked to the discussion to be had in #113654

[rustbot]

r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

[workingjubilee]

Hmm, I'm assuming this isn't going to affect anything but I would like to see the perf queue say "yes" first.

@bors try @rust-timer queue

[bors]

⌛ Trying commit 8655cbf with merge 3df3b2c...

[bors]

☀️ Try build successful - checks-actions
Build commit: 3df3b2c (3df3b2ce4774fef0dbbc6f02e92cdad8275ee162)

[bors]

☀️ Try build successful - checks-actions
Build commit: 3df3b2c (3df3b2ce4774fef0dbbc6f02e92cdad8275ee162)

[rust-timer]

Finished benchmarking commit (3df3b2c): comparison URL.

Overall result: ❌ regressions - 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 a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.5%, 0.5%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.5%	[0.5%, 0.5%]	1

Max RSS (memory usage)

Results

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)	6.7%	[6.7%, 6.7%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-2.8%	[-3.2%, -2.5%]	4
All ❌✅ (primary)	2.0%	[-2.8%, 6.7%]	2

Cycles

Results

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)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	2.5%	[2.2%, 2.8%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.0%	[1.0%, 1.0%]	1

Binary size

Results

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.3%	[0.3%, 0.3%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.1%]	5
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.1%	[-0.3%, 0.3%]	6

Bootstrap: 675.106s -> 674.558s (-0.08%)
Artifact size: 314.16 MiB -> 314.13 MiB (-0.01%)

[workingjubilee]

Hm. Sure. Don't know whether the other changes should be done, but the shocking lack of runtime perf changes feels motivating.

@bors r+

[bors]

📌 Commit 8655cbf has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit 8655cbf with merge 86b7b71...

[bors]

💔 Test failed - checks-actions

[workingjubilee]

uh?
@bors retry

[bors]

⌛ Testing commit 8655cbf with merge 7c76c7b...

[workingjubilee]

I'm going to just hand-audit this for every supported platform before I approve this again. Might be a few days before I get around to it.

[krtab]

Ok. I'm on break for the next two weeks anyway so no rush.

[bors]

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

[joboet]

There are still some unresolved imports and missing modules on some targets:

• Hermit (x86_64-unknown-hermit)
• SOLID (aarch64-kmc-solid_asp3)
• TeeOS (aarch64-unknown-teeos)
• UEFI still has a memchr module (x86_64-unknown-uefi)
• ZKVM does too (it doesn't currently build anyway)

I'd recommend searching all of std for memchr, checking each use, and then running x check library/std --target [TARGET] for each of the targets above, they should be representative.

[bors]

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

[rustbot]

This PR modifies src/bootstrap/defaults.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

[krtab]

@rustbot label -T-bootstrap

[krtab]

Thanks @joboet, it should hopefully be good know.
And thanks to @WaffleLapkin on zulip as well.

[workingjubilee]

Thank you everyone! Sorry for not getting back to you on answering your question on Zulip, the answer was a somewhat inane "manually comb through everything and run this code on the machines I have available".

@bors r+

[bors]

📌 Commit 88ac7ac has been approved by workingjubilee

It is now in the queue for this repository.

[workingjubilee]

@bors rollup=never

[bors]

⌛ Testing commit 88ac7ac with merge 6f435eb...

[bors]

☀️ Test successful - checks-actions
Approved by: workingjubilee
Pushing 6f435eb to master...

[rust-timer]

Finished benchmarking commit (6f435eb): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.7%	[-2.7%, -2.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.8%	[-2.7%, 1.1%]	2

Max RSS (memory usage)

Results

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)	15.9%	[15.9%, 15.9%]	1
Regressions ❌ (secondary)	2.8%	[0.9%, 6.1%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	15.9%	[15.9%, 15.9%]	1

Cycles

Results

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)	1.0%	[1.0%, 1.0%]	1
Regressions ❌ (secondary)	2.7%	[2.7%, 2.7%]	1
Improvements ✅ (primary)	-2.9%	[-2.9%, -2.9%]	1
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-0.9%	[-2.9%, 1.0%]	2

Binary size

Results

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.3%	[0.0%, 0.5%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.1%	[-0.1%, -0.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[-0.1%, 0.5%]	3

Bootstrap: 651.937s -> 650.561s (-0.21%)
Artifact size: 311.55 MiB -> 311.48 MiB (-0.02%)

[lqd]

The regression doesn’t look real, syn-opt was somehow less noisy than usual recently, and seems to be back to its usual behavior.