Port outline-atomics to rust

[jyn514]

This has a very long history, summarized in rust-lang/rust#109064. This port is a very minimal subset of aarch64/lse.S from LLVM's compiler-rt. In particular, it is missing the following:

1. Any form of runtime dispatch between LL/SC and LSE.
   Determining which version of the intrinsics to use requires one of the following:

   1. getauxval from glibc. It's unclear whether compiler_builtins is
      allowed to depend on libc at all, and musl's support for getauxval interacts poorly with the static linking shenanigans rustc does by default. Don't enshrine the requirement "de-facto" by making it required for outline-atomics.
   2. kernel support. Linux and FreeBSD have limited support, but it
      requires an extremely recent kernel version and doesn't work at all under QEMU (+outline-atomics violates "core shall not depend on libc" rust#109064 (comment)).

   Instead, we hard-code LL/SC intrinsics. Users who want LSE support should use the LLVM compiler-rt (if you're building from source in rust-lang/rust, make sure you have src/llvm-project checked out locally. the goal is to soon add a new optimized-compiler-builtins option so this is easier to discover).

2. The global ___aarch64_have_lse_atomics CTOR, required to do runtime dispatch without runtime overhead that defeats the point of the LSE intrinsics. @thomcc has this to say about global CTORs:

   static ctors are problems because we are pretty eager about dead code elim
   in general if you have a module that isnt directly reference we will probably not have its static ctors
   also, while llvm has a super robust way to have a static ctor (theres s special "appending global" to use for c++), we dont use that and just have people make a #[used] static in a special section

   1. the robust way kinda requires rust knowing that the argument is a static ctor (maybe a #[rustc_static_ctor] attribute). it also would be... finnicky, since on windows we actually care beyond being a static ctor, that we run as part in a specific group of ctors, which means a very specific section (one for TLS and the other for, uh, i dont remember)
   2. we still actually have to codegen the cgu that isn't referenced. but maybe we could remember that it has that attribute and use that

   So while this is possible in theory, it's decidedly non-trivial, and needs invasive changes to rustc itself. In any case, it doesn't matter until we decide the story around libc.

Note that 16-bytes CAS is not used at all in the standard library that I can find, so unlike the rest of these ops it's only tested by the unit tests, not by any real usage.

[bjorn3]

Instead, we hard-code LL/SC intrinsics. Users who want LSE support should use the LLVM compiler-rt (if you're building from source in rust-lang/rust, make sure you have src/llvm-project checked out locally. the goal is to soon add a new optimized-compiler-builtins option so this is easier to discover).

compiler-builtins takes priority over compiler-rt amd libgcc as it comes first in the linker order. On desktop OSes where these intrinsics actually matter you already get either libgcc or compiler-rt as dependency by gcc/clang when they act as linker.

[bjorn3]

Can you please make this respect the no-asm feature. Cg_clif needs this as it doesn't support inline asm on AArch64 yet.

[thomcc]

(Note that I think I wrote the quoted message when I was very tired several months ago, so I'm not sure it's as, err, polished as might be desirable. I think it's mostly correct, but I don't really remember what I was talking about with regards to the windows stuff)

[taiki-e]

Determining which version of the intrinsics to use requires one of the following:

FYI, the latest release of the Linux kernel (6.4) has added a way to read auxv without depending on either libc or mrs trap (torvalds/linux@ddc6597). It is more complicated than just calling getauxval since it requires using asm to call syscall and then also parsing auxv, but if versions of the kernel that supports it becomes widely used in the future, we might want to use that way.

It is also possible to get auxv without depending on libc by calling syscall using asm even on FreeBSD. However, IIRC, FreeBSD does not guarantee the stability of raw syscall as much as Linux does (It may actually be stable enough, though).

(I think I can talk about other operating systems if needed (such as those listed here, or NetBSD, which is not yet listed).)

musl doesn't even support getauxval.

No, musl supports getauxvel since 1.1.0. AFAIK, the problem with musl seems to be that getauxval is not well recognized when using static linking (maybe due to linking modifier or order). (See also this comment for the availability of getauxval in various libc.)

[jyn514]

Instead, we hard-code LL/SC intrinsics. Users who want LSE support should use the LLVM compiler-rt (if you're building from source in rust-lang/rust, make sure you have src/llvm-project checked out locally. the goal is to soon add a new optimized-compiler-builtins option so this is easier to discover).

compiler-builtins takes priority over compiler-rt amd libgcc as it comes first in the linker order. On desktop OSes where these intrinsics actually matter you already get either libgcc or compiler-rt as dependency by gcc/clang when they act as linker.

When the c feature is enabled, we don't compile this code at all:

compiler-builtins/src/macros.rs

Lines 192 to 233 in ba44f2e

	// Right now there's a bunch of architecture-optimized intrinsics in the
	// stock compiler-rt implementation. Not all of these have been ported over
	// to Rust yet so when the `c` feature of this crate is enabled we fall back
	// to the architecture-specific versions which should be more optimized. The
	// purpose of this macro is to easily allow specifying this.
	//
	// The `#[maybe_use_optimized_c_shim]` attribute indicates that this
	// intrinsic may have an optimized C version. In these situations the build
	// script, if the C code is enabled and compiled, will emit a cfg directive
	// to get passed to rustc for our compilation. If that cfg is set we skip
	// the Rust implementation, but if the attribute is not enabled then we
	// compile in the Rust implementation.
	(
	#[maybe_use_optimized_c_shim]
	$(#[$($attr:tt)*])*
	pub extern $abi:tt fn $name:ident( $($argname:ident: $ty:ty),* ) $(-> $ret:ty)? {
	$($body:tt)*
	}
	$($rest:tt)*
	) => (
	#[cfg($name = "optimized-c")]
	#[cfg_attr(feature = "weak-intrinsics", linkage = "weak")]
	pub extern $abi fn $name( $($argname: $ty),* ) $(-> $ret)? {
	extern $abi {
	fn $name($($argname: $ty),*) $(-> $ret)?;
	}
	unsafe {
	$name($($argname),*)
	}
	}
	#[cfg(not($name = "optimized-c"))]
	intrinsics! {
	$(#[$($attr)*])*
	pub extern $abi fn $name( $($argname: $ty),* ) $(-> $ret)? {
	$($body)*
	}
	}
	intrinsics!($($rest)*);
	);

so the linker precedence shouldn't matter. We never distribute compiler_builtins with the C feature disabled that i know of.

Can you please make this respect the no-asm feature. Cg_clif needs this as it doesn't support inline asm on AArch64 yet.

👍 will do