mirror of
https://github.com/rust-lang/rust.git
synced 2025-11-24 07:37:18 +00:00
21c821c6c9
This has a very long history, summarized in https://github.com/rust-lang/rust/issues/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: i) `getauxval` from glibc. It's unclear whether `compiler_builtins` is allowed to depend on libc at all, and musl doesn't even support getauxval. Don't enshrine the requirement "de-facto" by making it required for outline-atomics. ii) kernel support. Linux and FreeBSD have limited support, but it requires an extremely recent kernel version and doesn't work at all under QEMU (https://github.com/rust-lang/rust/issues/109064#issuecomment-1494939904). 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. Thom Chiviolani 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 rust itself. In any case, it doesn't matter until we decide the story around libc. 3. The 16-byte (i128) version of compare_and_swap. This wouldn't be *too* hard to add, but it would be hard to test. The way I tested the existing code was not just with unit tests but also by loading it as a path dependency and running `x test core` - the latter caught several bugs the unit tests didn't catch (because I originally wrote the tests wrong). So I am slightly nervous about adding a 16-byte version that is much more poorly tested than the other intrinsics.
libm @ 1dbb9d2d47
compiler-builtins
Porting
compiler-rtintrinsics to Rust
See rust-lang/rust#35437.
When and how to use this crate?
If you are working with a target that doesn't have binary releases of std
available via rustup (this probably means you are building the core crate
yourself) and need compiler-rt intrinsics (i.e. you are probably getting linker
errors when building an executable: undefined reference to __aeabi_memcpy),
you can use this crate to get those intrinsics and solve the linker errors. To
do that, add this crate somewhere in the dependency graph of the crate you are
building:
# Cargo.toml
[dependencies]
compiler_builtins = { git = "https://github.com/rust-lang/compiler-builtins" }
extern crate compiler_builtins;
// ...
If you still get an "undefined reference to $INTRINSIC" error after that change,
that means that we haven't ported $INTRINSIC to Rust yet! Please open an
issue with the name of the intrinsic and the LLVM triple (e.g.
thumbv7m-none-eabi) of the target you are using. That way we can prioritize
porting that particular intrinsic.
If you've got a C compiler available for your target then while we implement this intrinsic you can temporarily enable a fallback to the actual compiler-rt implementation as well for unimplemented intrinsics:
[dependencies.compiler_builtins]
git = "https://github.com/rust-lang/compiler-builtins"
features = ["c"]
Contributing
- Pick one or more intrinsics from the pending list.
- Fork this repository.
- Port the intrinsic(s) and their corresponding unit tests from their C implementation to Rust.
- Implement a test generator to compare the behavior of the ported intrinsic(s)
with their implementation on the testing host. Note that randomized compiler-builtin tests
should be run using
cargo test --features gen-tests. - Send a Pull Request (PR).
- Once the PR passes our extensive testing infrastructure, we'll merge it!
- Celebrate 🎉
Porting Reminders
- Rust and C have slightly different operator precedence. C evaluates comparisons (
== !=) before bitwise operations (& | ^), while Rust evaluates the other way. - C assumes wrapping operations everywhere. Rust panics on overflow when in debug mode. Consider using the Wrapping type or the explicit wrapping_* functions where applicable.
- Note C implicit casts, especially integer promotion. Rust is much more explicit about casting, so be sure that any cast which affects the output is ported to the Rust implementation.
- Rust has many functions for integer or floating point manipulation in the standard library. Consider using one of these functions rather than porting a new one.
Progress
- adddf3.c
- addsf3.c
- arm/adddf3vfp.S
- arm/addsf3vfp.S
- arm/aeabi_dcmp.S
- arm/aeabi_fcmp.S
- arm/aeabi_idivmod.S
- arm/aeabi_ldivmod.S
- arm/aeabi_memcpy.S
- arm/aeabi_memmove.S
- arm/aeabi_memset.S
- arm/aeabi_uidivmod.S
- arm/aeabi_uldivmod.S
- arm/divdf3vfp.S
- arm/divmodsi4.S (generic version is done)
- arm/divsf3vfp.S
- arm/divsi3.S (generic version is done)
- arm/eqdf2vfp.S
- arm/eqsf2vfp.S
- arm/extendsfdf2vfp.S
- arm/fixdfsivfp.S
- arm/fixsfsivfp.S
- arm/fixunsdfsivfp.S
- arm/fixunssfsivfp.S
- arm/floatsidfvfp.S
- arm/floatsisfvfp.S
- arm/floatunssidfvfp.S
- arm/floatunssisfvfp.S
- arm/gedf2vfp.S
- arm/gesf2vfp.S
- arm/gtdf2vfp.S
- arm/gtsf2vfp.S
- arm/ledf2vfp.S
- arm/lesf2vfp.S
- arm/ltdf2vfp.S
- arm/ltsf2vfp.S
- arm/modsi3.S (generic version is done)
- arm/muldf3vfp.S
- arm/mulsf3vfp.S
- arm/nedf2vfp.S
- arm/negdf2vfp.S
- arm/negsf2vfp.S
- arm/nesf2vfp.S
- arm/softfloat-alias.list
- arm/subdf3vfp.S
- arm/subsf3vfp.S
- arm/truncdfsf2vfp.S
- arm/udivmodsi4.S (generic version is done)
- arm/udivsi3.S (generic version is done)
- arm/umodsi3.S (generic version is done)
- arm/unorddf2vfp.S
- arm/unordsf2vfp.S
- ashldi3.c
- ashrdi3.c
- comparedf2.c
- comparesf2.c
- divdf3.c
- divdi3.c
- divmoddi4.c
- divmodsi4.c
- divsf3.c
- divsi3.c
- extendhfsf2.c
- extendsfdf2.c
- fixdfdi.c
- fixdfsi.c
- fixsfdi.c
- fixsfsi.c
- fixunsdfdi.c
- fixunsdfsi.c
- fixunssfdi.c
- fixunssfsi.c
- floatdidf.c
- floatdisf.c
- floatsidf.c
- floatsisf.c
- floatundidf.c
- floatundisf.c
- floatunsidf.c
- floatunsisf.c
- i386/ashldi3.S
- i386/ashrdi3.S
- i386/chkstk.S
- i386/chkstk2.S
- i386/divdi3.S
- i386/lshrdi3.S
- i386/moddi3.S
- i386/muldi3.S
- i386/udivdi3.S
- i386/umoddi3.S
- lshrdi3.c
- moddi3.c
- modsi3.c
- muldf3.c
- muldi3.c
- mulodi4.c
- mulosi4.c
- mulsf3.c
- powidf2.c
- powisf2.c
- subdf3.c
- subsf3.c
- truncdfhf2.c
- truncdfsf2.c
- truncsfhf2.c
- udivdi3.c
- udivmoddi4.c
- udivmodsi4.c
- udivsi3.c
- umoddi3.c
- umodsi3.c
- x86_64/chkstk.S
- x86_64/chkstk2.S
These builtins are needed to support 128-bit integers, which are in the process of being added to Rust.
- ashlti3.c
- ashrti3.c
- divti3.c
- fixdfti.c
- fixsfti.c
- fixunsdfti.c
- fixunssfti.c
- floattidf.c
- floattisf.c
- floatuntidf.c
- floatuntisf.c
- lshrti3.c
- modti3.c
- muloti4.c
- multi3.c
- udivmodti4.c
- udivti3.c
- umodti3.c
Unimplemented functions
These builtins involve floating-point types ("f128", "f80" and complex numbers) that are not supported by Rust.
addtf3.ccomparetf2.cdivdc3.cdivsc3.cdivtc3.cdivtf3.cdivxc3.cextenddftf2.cextendsftf2.cfixtfdi.cfixtfsi.cfixtfti.cfixunstfdi.cfixunstfsi.cfixunstfti.cfixunsxfdi.cfixunsxfsi.cfixunsxfti.cfixxfdi.cfixxfti.cfloatditf.cfloatdixf.cfloatsitf.cfloattixf.cfloatunditf.cfloatundixf.cfloatunsitf.cfloatuntixf.ci386/floatdixf.Si386/floatundixf.Smuldc3.cmulsc3.cmultc3.cmultf3.cmulxc3.cpowitf2.cpowixf2.cppc/divtc3.cppc/fixtfdi.cppc/fixunstfdi.cppc/floatditf.cppc/floatunditf.cppc/gcc_qadd.cppc/gcc_qdiv.cppc/gcc_qmul.cppc/gcc_qsub.cppc/multc3.csubtf3.ctrunctfdf2.ctrunctfsf2.cx86_64/floatdixf.cx86_64/floatundixf.S
These builtins are never called by LLVM.
absvdi2.cabsvsi2.cabsvti2.caddvdi3.caddvsi3.caddvti3.carm/aeabi_cdcmp.Sarm/aeabi_cdcmpeq_check_nan.carm/aeabi_cfcmp.Sarm/aeabi_cfcmpeq_check_nan.carm/aeabi_div0.carm/aeabi_drsub.carm/aeabi_frsub.carm/aeabi_memcmp.Sarm/bswapdi2.Sarm/bswapsi2.Sarm/clzdi2.Sarm/clzsi2.Sarm/comparesf2.Sarm/restore_vfp_d8_d15_regs.Sarm/save_vfp_d8_d15_regs.Sarm/switch16.Sarm/switch32.Sarm/switch8.Sarm/switchu8.Sclzdi2.cclzsi2.cclzti2.ccmpdi2.ccmpti2.cctzdi2.cctzsi2.cctzti2.cffsdi2.c- this is called by gcc though!ffsti2.cmulvdi3.cmulvsi3.cmulvti3.cnegdf2.cnegdi2.cnegsf2.cnegti2.cnegvdi2.cnegvsi2.cnegvti2.cparitydi2.cparitysi2.cparityti2.cpopcountdi2.cpopcountsi2.cpopcountti2.cppc/restFP.Sppc/saveFP.Ssubvdi3.csubvsi3.csubvti3.cucmpdi2.cucmpti2.cudivmodti4.c
Rust only exposes atomic types on platforms that support them, and therefore does not need to fall back to software implementations.
arm/sync_fetch_and_add_4.Sarm/sync_fetch_and_add_8.Sarm/sync_fetch_and_and_4.Sarm/sync_fetch_and_and_8.Sarm/sync_fetch_and_max_4.Sarm/sync_fetch_and_max_8.Sarm/sync_fetch_and_min_4.Sarm/sync_fetch_and_min_8.Sarm/sync_fetch_and_nand_4.Sarm/sync_fetch_and_nand_8.Sarm/sync_fetch_and_or_4.Sarm/sync_fetch_and_or_8.Sarm/sync_fetch_and_sub_4.Sarm/sync_fetch_and_sub_8.Sarm/sync_fetch_and_umax_4.Sarm/sync_fetch_and_umax_8.Sarm/sync_fetch_and_umin_4.Sarm/sync_fetch_and_umin_8.Sarm/sync_fetch_and_xor_4.Sarm/sync_fetch_and_xor_8.Sarm/sync_synchronize.Satomic.catomic_flag_clear.catomic_flag_clear_explicit.catomic_flag_test_and_set.catomic_flag_test_and_set_explicit.catomic_signal_fence.catomic_thread_fence.c
Miscellaneous functionality that is not used by Rust.
apple_versioning.cclear_cache.cemutls.cenable_execute_stack.ceprintf.cgcc_personality_v0.ctrampoline_setup.c
Floating-point implementations of builtins that are only called from soft-float code. It would be better to simply use the generic soft-float versions in this case.
i386/floatdidf.Si386/floatdisf.Si386/floatundidf.Si386/floatundisf.Sx86_64/floatundidf.Sx86_64/floatundisf.Sx86_64/floatdidf.cx86_64/floatdisf.c
License
The compiler-builtins crate is dual licensed under both the University of Illinois "BSD-Like" license and the MIT license. As a user of this code you may choose to use it under either license. As a contributor, you agree to allow your code to be used under both.
Full text of the relevant licenses is in LICENSE.TXT.