Currently, Cargo.toml specifies Apache-2.0 OR MIT, but LICENSE.txt
describes MIT OR NCSA. compiler-builtins is derived from LLVM's
compiler-rt. LICENSE.txt correctly reflects the state of compiler-rt
prior to relicensing on 2019-01-19, during which time software was
available for use under either MIT or the University of Illinois NCSA
license. After relicensing, however, compiler-rt is available for use
only under Apache-2.0 with the LLVM exception; this is not reflected
anywhere in the repository.
Update the SPDX license identifier to `MIT AND Apache-2.0 WITH
LLVM-exception AND (MIT OR Apache-2.0)`. Each AND portion covers
something specific:
* Apache-2.0 WITH LLVM-exception: this covers work that is derived from
the LLVM repository since after the LLVM relicensing.
* MIT: This covers work that is derived from LLVM before the LLVM
relicensing (under MIT OR NCSA), as well as the vendored `libm`
components.
* MIT AND Apache-2.0: This ensures that any contributions to this
repository, in addition to meeting the above required licenses, is
also released for use under the Rust-standard Apache-2.0 with no LLVM
exception.
See also the parallel license update in rust-lang/libm [1].
Fixes: https://github.com/rust-lang/compiler-builtins/issues/307
Closes: https://github.com/rust-lang/compiler-builtins/pull/511
Link: https://rust-lang.zulipchat.com/#narrow/channel/335408-foundation/topic/Request.20for.20legal.20team.20input.20on.20crate.20licensing
Link: https://github.com/rust-lang/libm/pull/317 [1]
`to_bits` and `from_bits` are builtin methods on float types. Rename
`repr` to `to_bits` and `from_repr` to `from_bits` so this is consistent
with usage that doesn't go through the trait.
Please, see this discussion for the full
context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.5Bwasm32.5D.20Infinite.20recursion.20.60compiler-builtins.60.20.60__multi3.60
Signed-off-by: Enzo "raskyld" Nocera <enzo@nocera.eu>
We determined that some recursion problems on SPARC and WASM were due to
infinite recusion. This was introduced at 9c6fcb56e8 ("Split Int into
Int and MinInt") when moving the implementation of `widen_hi` from
something on each `impl` block to a default on the trait. The reasoning
is not fully understood, but undoing this portion of the change seems to
resolve the issue.
[ add the above context - Trevor ]
Signed-off-by: Trevor Gross <tmgross@umich.edu>
<https://github.com/rust-lang/rust/issues/126984> has been resolved.
Remove the workaround that was introduced to suppress it.
This reverts commit 254edbcad4cfd6a8af32e3297c1037d7984c3c49.
Float division currently has a separate `div32` and `div64` for `f32`
and `f64`, respectively. Combine these to make use of generics. This
will make it easier to support `f128` division, and reduces a lot of
redundant code.
This includes a simplification of division tests.
Add some bounds to integer types that allow our function trait bounds to
be slightly less verbose. Also clarify documentation and remove a
redundant operation.
This commit updates the `#[cfg]` annotations used to select the
implementation of 128-bit division in compiler-builtins on wasm targets.
This is done with relation to
https://github.com/WebAssembly/128-bit-arithmetic where performance of
128-bit operations is being investigated on WebAssembly. While I don't
know much about the particulars of the two algorithms involved here the
comments indicate that the "trifecta" variant is preferred if possible
but it's not selected on 32-bit architectures. This rationale isn't as
applicable to WebAssembly targets because despite the 32-bit pointer
width there are often wider-than-pointer operations available as it's
typically run on 64-bit machines.
Locally in testing a benchmark that performs division with a Rust-based
bignum libraries whent from 350% slower-than-native to 220%
slower-than-native with this change, a nice increase in speed. While
this was tested with Wasmtime other runtimes are likely to see an
improvement as well.
These hexagon builtins incorrectly created aliases in the global
namespace which can (and in at least one case, did) conflict
with symbols defined by other programs.
This should address the issue reported as https://github.com/rust-lang/rust/issues/129823:
Compiling compiler_builtins v0.1.123
Compiling core v0.0.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
Compiling rustc-std-workspace-core v1.99.0 (/home/ben/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling byteorder v1.5.0
Compiling zerocopy v0.7.34
error: symbol 'fma' is already defined
error: could not compile `compiler_builtins` (lib) due to 1 previous error
Also: some of the symbols defined were not just aliases, so those are
now qualified with `__hexagon_`. The compiler does not yet emit calls
to these particular ones, but if/when it does, it can use the new names.
This fixes such as (https://github.com/rust-lang/rust/issues/128386)
where, our implementation is being used on systems where there is
already `math` library and its more performant and accurate.
So with this change, linux will go back to the previous behavior and not
include these functions, windows and apple were generally not affected.
Looking at the targets we have builtin now in rust, everything else is
probably good to have the math symbols.
> A note on the above, the `hermit` os uses `libm` directly for itself,
> but I think its Ok to keep providing math in `compiler_builtin` for it,
> its technically the same implementation either from `compiler_builtin`
> or `hermit-builtins`.
Signed-off-by: Amjad Alsharafi <26300843+Amjad50@users.noreply.github.com>
