perf experiment: remove noalias, readonly, dereferenceable attributes

[RalfJung]

We sometimes get claims that these attributes aren't worth it, e.g. in a current discussion on the LKML. Let's see if we can get useful evidence just with the compiler test suite. I hope I got the diff right.^^

Cc @Darksonn @ojeda @saethlin @nikic

[rustbot]

r? @fmease

rustbot has assigned @fmease.
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

[RalfJung]

@bors try
@rust-timer queue

[bors]

⌛ Trying commit c51e453 with merge 8d95477...

[bors]

☀️ Try build successful - checks-actions
Build commit: 8d95477 (8d95477b52d4c4418dfaa65a3d8cea9928a76763)

[rust-timer]

Finished benchmarking commit (8d95477): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@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.7%	[0.2%, 4.0%]	65
Regressions ❌ (secondary)	1.2%	[0.2%, 12.9%]	77
Improvements ✅ (primary)	-1.8%	[-26.9%, -0.3%]	41
Improvements ✅ (secondary)	-1.6%	[-7.1%, -0.2%]	36
All ❌✅ (primary)	-0.3%	[-26.9%, 4.0%]	106

Max RSS (memory usage)

Results (primary 0.5%, secondary -0.7%)

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.1%	[2.6%, 3.6%]	2
Regressions ❌ (secondary)	5.1%	[5.1%, 5.1%]	1
Improvements ✅ (primary)	-4.6%	[-4.6%, -4.6%]	1
Improvements ✅ (secondary)	-2.6%	[-2.8%, -2.5%]	3
All ❌✅ (primary)	0.5%	[-4.6%, 3.6%]	3

Cycles

Results (primary -0.5%, secondary -0.0%)

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)	2.4%	[1.2%, 3.8%]	18
Regressions ❌ (secondary)	2.6%	[1.3%, 6.8%]	18
Improvements ✅ (primary)	-3.7%	[-28.9%, -0.8%]	17
Improvements ✅ (secondary)	-3.8%	[-6.5%, -2.0%]	13
All ❌✅ (primary)	-0.5%	[-28.9%, 3.8%]	35

Binary size

Results (primary -0.0%, secondary -1.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.6%	[0.1%, 1.4%]	32
Regressions ❌ (secondary)	2.9%	[0.4%, 12.1%]	5
Improvements ✅ (primary)	-0.6%	[-1.5%, -0.0%]	34
Improvements ✅ (secondary)	-1.4%	[-2.2%, -0.6%]	76
All ❌✅ (primary)	-0.0%	[-1.5%, 1.4%]	66

Bootstrap: 770.531s -> 759.113s (-1.48%)
Artifact size: 361.97 MiB -> 361.35 MiB (-0.17%)

[RalfJung]

The compiler does less work, so many compilation sessions getting faster is expected. Some getting slower means that the optimization really kicked in there, but it's not a slam-dunk result.

Even some runtime benchmarks get faster, which is... quite surprising?

[ojeda]

Yeah, the runtime ones are quite surprising, especially considering it is supposed to include not just noalias...

[Kobzol]

I would look at cycles/walltime for the runtime benchmarks for such a change. The raytracer benchmark got a 15% regression, which is well above its noise limit.

But this change would be better examined on a better range of runtime benchmarks than the small set we have on rustc-perf.

[the8472]

You can look at check and doc results since those exercise Rust code (rustc itself) and don't involve the backend doing less work. And those are mostly red, but not massively so.

IIRC some issues that users filed where noalias was a benefit were often compute kernels running over multiple slices that vectorized better when the backend knows they don't alias. rustc probably is too branchy for that particular benefit.

[saethlin]

Even some runtime benchmarks get faster, which is... quite surprising?

In #121068 I found that that only emitting getelementptr not getelementptr inbounds made the hashmap-related runtime benchmarks faster. This was fixed in an LLVM update. I never looked more closely into it than that.

So I'm only a little surprised by this perf report. I suspect there are code paths in LLVM where checks are written too strictly and just fail to apply when attributes are present. It would be great to minimize some of these regressions.

[saethlin]

I can reproduce the wall time regression for the raytracer benchmark locally, but I can't find any difference in the generated code for the hottest functions. Strange...

[Noratrieb]

could be a function layout thing

[saethlin]

I am not even sure what you mean by that. If this were caused by something like getting a lucky/unlucky address for some important instructions we would expect to see fluctuations of this magnitude all the time and we don't.

[Noratrieb]

Yeah I did mean function address layout, which is known to be prone to causing perf differences. But you are right that this would happen more often if it made that big of a difference.