atomic_load intrinsic: use const generic parameter for ordering

[RalfJung]

We have a gazillion intrinsics for the atomics because we encode the ordering into the intrinsic name rather than making it a parameter. This is particularly bad for those operations that take two orderings. Let's fix that!

This PR only converts load, to see if there's any feedback that would fundamentally change the strategy we pursue for the const generic intrinsics.

The first two commits are preparation and could be a separate PR if you prefer.

@BoxyUwU -- I hope this is a use of const generics that is unlikely to explode? All we need is a const generic of enum type. We could funnel it through an integer if we had to but an enum is obviously nicer...

@bjorn3 it seems like the cranelift backend entirely ignores the ordering?

[rustbot]

r? @fee1-dead

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

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred to the CTFE / Miri interpreter

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

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[bjorn3]

@bjorn3 it seems like the cranelift backend entirely ignores the ordering?

Correct. Wasm and by extension Cranelift only have SeqCst atomics.

[bjorn3]

You should probably just embed the discriminants directly in cg_ssa. The libstd cg_ssa is compiled against may use different discriminants from the one that rustc will end up compiling.

[RalfJung]

I followed what we already do for cmp::Ordering where we also rely on the discriminants to be the same.

[bjorn3]

Ordering is stable with guaranteed discriminant values, AtomicOrdering is not stable and I assume never will be, or at least not in the current location.

[RalfJung]

AtomicOrdering got specifically added for this very purpose. It's going to be exactly as stable as we need it for this purpose.

[BoxyUwU]

I hope this is a use of const generics that is unlikely to explode

I think that anything the compiler lets you do with solely adt_const_params (i.e. not unsized_const_params) should work perfectly fine. AFAIK the only outstanding issue with the feature is the problems around CTFE being invoked on illformed bodies but that should only matter for code that doesn't compile. tl;dr I don't see any problems with using an enum in const generics in std.