allow mutating function args through &raw const

[lukas-code]

Fixes #111502 by "turning off the sketchy optimization while we figure out if this is ok", like @JakobDegen said.

The first commit in this PR removes some suspicious looking logic from the same method, but should have no functional changes, since it doesn't modify the context outside of the method. Best reviewed commit by commit.

r? opsem

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[RalfJung]

Opsem can help analyze whether an opt is correct, but at least I lack the experience to actually review their implementations.

r? mir-opt

[tmiasko]

Thanks.

@bors r+

[bors]

📌 Commit 9c418e5 has been approved by tmiasko

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9c418e5 with merge 3603a84...

[bors]

☀️ Test successful - checks-actions
Approved by: tmiasko
Pushing 3603a84 to master...

[rust-timer]

Finished benchmarking commit (3603a84): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

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

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

Binary size

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

Bootstrap: 660.495s -> 659.942s (-0.08%)

[RalfJung]

Why is it okay to consider indirect places immutable? I have no idea what kind of code this affects, but it seems very suspicious to me that whether or not the place is indirect would make any difference.

[lukas-code]

If you have

fn foo(arg: *const u8) { /* ... */ }

then addr_of!(*arg) can't change the value of arg, only addr_of!(arg) can.

In practice, this doesn't actually make a difference and we could always return true here, because currently

1. single pointers are never passed indirectly
2. when accessing a pointer in a compound type, e.g. addr_of!(*(arg.ptr)) this operation is split in two mir statements let tmp = deref_copy arg.ptr and &raw const *tmp and so this &raw const already doesn't affect whether arg is readonly.

[RalfJung]

then addr_of!(*arg) can't change the value of arg, only addr_of!(arg) can.

This should apply uniformly to &[raw] [mut|const] (including regular non-raw borrows) then, right?

[lukas-code]

That seems to be correct. In that case I'd probably just remove the special case here (and just return true) rather than introduce more special casing, because it doesn't actually matter.

[RalfJung]

Sounds good to me.