atomicrmw on pointers: move integer-pointer cast hacks into backend

[RalfJung]

Conceptually, we want to have atomic operations on pointers of the form fn atomic_add(ptr: *mut T, offset: usize, ...). However, LLVM does not directly support such operations (llvm/llvm-project#120837), so we have to cast the offset to a pointer somewhere.

This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.

Cc @nikic -- this is the best we can do right now, right?
Fixes #134617

[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

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

The Miri subtree was changed

cc @rust-lang/miri

[nikic]

This is now doing something pretty weird where this code casts the integer to pointer and then bx.atomic_rmw is going to cast it back to integer.

LLVM already expects the arguments to atomicrmw here to be a pointer and an integer. Now that the Rust intrinsic no longer artificially forces both arguments to be pointers, we should remove both this cast and the argument cast in atomic_rmw.

The only cast you need to keep is the cast of the return value of atomicrmw.

[RalfJung]

This is now doing something pretty weird where this code casts the integer to pointer and then bx.atomic_rmw is going to cast it back to integer.

Ah, fair.

LLVM already expects the arguments to atomicrmw here to be a pointer and an integer.

Ah right, it expects a pointer-to-integer and an integer (when it really should be ptr-to-ptr and integer, for RMWs on pointers).

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[RalfJung]

@antoyo, @GuillaumeGomez I took a wild guess with those GCC changes, please take a look.

@bjorn3 this seems to somehow break cranelift, which is surprising since I thought usize and raw pointers were the same type there. Any idea what is happening?

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[RalfJung]

I took a guess at what I have to do in cranelift, I hope it makes sense.

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[RalfJung]

I think this test might actually have been ineffective ever since we gained that heuristic that automatically marks small functions as #[inline].