As of LLVM 9.0, certain calls to memcmp may be converted to bcmp, which I guess
could save a single subtraction on some architectures. [1]
bcmp is just like memcmp except instead of returning the difference between the
two differing bytes, it returns non-zero instead. As such, memcmp is a valid
implementation of bcmp.
If we care about size, bcmp should just call memcmp.
If we care about speed, we can change bcmp to look like this instead:
```rust
pub unsafe extern "C" fn bcmp(s1: *const u8, s2: *const u8, n: usize) -> i32 {
let mut i = 0;
while i < n {
let a = *s1.offset(i as isize);
let b = *s2.offset(i as isize);
if a != b {
return 1;
}
i += 1;
}
0
}
```
In this PR I do not address any changes which may or may not be needed for arm
aebi as I lack proper test hardware.
[1]: https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#noteworthy-optimizations
This turns the following backtrace,
```
>> bt
#0 0x0000555555576f73 in __rust_probestack () at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.14/src/probestack.rs:55
Backtrace stopped: Cannot access memory at address 0x7fffff7fedf0
```
To this:
```
>>> bt
#0 0x0000555555574e47 in __rust_probestack ()
#1 0x00005555555595ba in test::main ()
#2 0x00005555555594f3 in std::rt::lang_start::{{closure}} ()
#3 0x0000555555561ae3 in std::panicking::try::do_call ()
#4 0x000055555556595a in __rust_maybe_catch_panic ()
#5 0x000055555555af9b in std::rt::lang_start_internal ()
#6 0x00005555555594d5 in std::rt::lang_start ()
#7 0x000055555555977b in main ()
```
The -Zlower-128bit-ops feature is completely broken, as libcore needs
those lang items to compile with this feature, but they are only
provided by compiler_builtins, which itself depends on libcore.
According to rust-lang/rust#58969 the feature never got finished.
This commit removes the associated lang items and replaces them with
normal unmangled functions, when there is no existing intrinsic. This
makes it easier for alternative codegen backends to implement 128bit
integer support.
This commit removes the `compiler-rt` submodule from this repository.
The goal here is to align the `compiler-rt` used for compiling C
intrinsics with the upstream rust-lang/rust's usage of `llvm-project`.
Currently we have both an `llvm-project` repository as well as
`compiler-rt`, but they can naturally get out of sync and it's just one
more submodule to manage.
The thinking here is that the feature `c` for this crate, when
activated, will require the user to configure where the source code for
`compiler-rt` is present. This places the onus on the builder of
`compiler-builtins` to check-out and arrange for the appropriate
`compiler-rt` source code to be placed somewhere. For rust-lang/rust
this is already done with the `llvm-project` submodule, and we can
arrange for it to happen on this crate's CI anyway.
For users of this crate this is a bit of a bummer, but `c` is disabled
by default anyway and it seems unlikely that `c` is explicitly opted in
to all that much. (given the purpose of this crate)
This should allow us to archive the `compiler-rt` repository and simply
use `llvm-project` in the rust-lang/rust repository.
This commit tweaks the implementation of the synthetic
`#[use_c_shim_if]` attribute, renaming it to
`#[maybe_use_optimized_c_shim]` in the process. This no longer requires
specifying a `#[cfg]` clause indicating when the optimized intrinsic
should be used, but rather this is inferred and printed from the build
script.
The build script will now print out appropriate `#[cfg]` directives for
rustc to indicate what intrinsics it's compiling. This should remove the
need for us to keep the build script and the source in sync, but rather
the build script can simply take care of everything.
