This used to be disabled due to LLVM bugs in the handling of
noalias information in conjunction with unwinding. However,
according to #31681 all known LLVM bugs have been fixed by
LLVM 6.0, so it's probably time to reenable this optimization.
Noalias annotations will not be emitted by default if either
-C panic=abort (as previously) or LLVM >= 6.0 (new).
-Z mutable-noalias=no is left as an escape-hatch to allow
debugging problems suspected to stem from this change.
This reworks the force-frame-pointer PR to explicitly only consider the
value of the flag if it is provided, and use a target default otherwise.
Something that was tried but not kept was renaming the flag to
`frame-pointer`, because for flag `frame-pointer=no`, there is no
guarante, that LLVM will elide *all* the frame pointers; oposite of what
the literal reading of the flag would suggest.
We apparently used to generate bad/incomplete debug info causing
debuggers not to find symbols of stack allocated variables. This was
somehow worked around by having frame pointers.
With the current codegen, this seems no longer necessary, so we can
remove the code that force-enables frame pointers whenever debug info
is requested.
Since certain situations, like profiling code profit from having frame
pointers, we add a -Cforce-frame-pointers flag to always enable frame
pointers.
Fixes#11906
Previously the features specified to LLVM via `-C target-feature` were only
reflected in the `TargetMachine` but this change *also* reflects these and the
base features inside each function itself. This change matches clang and...
Closesrust-lang-nursery/stdsimd#427
Long ago (#40549) we enabled the `uwtable` attribute on Windows by default
(even with `-C panic=abort`) to allow unwinding binaries for [stack unwinding
information][winstack]. It looks like this same issue is [plaguing][arm1]
Gecko's Android platforms [as well][arm2]. This commit applies the same fix
as #40549 except that this time it's applied for all Android targets.
Generating a `-C panic=abort` binary for `armv7-linux-androideabi` before this
commit generated a number of `cantunwind` functions (detected with `readelf -u`)
but after this commit they all list appropriate unwind information.
Closes#49867
[winstack]: https://bugzilla.mozilla.org/show_bug.cgi?id=1302078
[arm1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1453220
[arm2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1451741
Better document the implementors of Clone and Copy
There are two parts to this change. The first part is a change to the compiler and to the standard library (specifically, libcore) to allow implementations of `Clone` and `Copy` to be written for a subset of builtin types. By adding these implementations to libcore, they now show up in the documentation. This is a [breaking-change] for users of `#![no_core]`, because they will now have to supply their own copy of the implementations of `Clone` and `Copy` that were added in libcore.
The second part is purely a documentation change to document the other implementors of `Clone` and `Copy` that cannot be described in Rust code (yet) and are thus provided by the compiler.
Fixes#25893
implement minmax intrinsics
This adds the `simd_{fmin,fmax}` intrinsics, which do a vertical (lane-wise) `min`/`max` for floating point vectors that's equivalent to Rust's `min`/`max` for `f32`/`f64`.
It might make sense to make `{f32,f64}::{min,max}` use the `minnum` and `minmax` intrinsics as well.
---
~~HELP: I need some help with these. Either I should go to sleep or there must be something that I must be missing. AFAICT I am calling the `maxnum` builder correctly, yet rustc/LLVM seem to insert a call to `llvm.minnum` there instead...~~ EDIT: Rust's LLVM version is too old :/
Simply checking for the presence of `llvm.memset` is too brittle because
this instrinsic can be used for seemingly trivial operations, such as
zero-initializing a `RawVec`.
Introduce unsafe offset_from on pointers
Adds intrinsics::exact_div to take advantage of the unsafe, which reduces the implementation from
```asm
sub rcx, rdx
mov rax, rcx
sar rax, 63
shr rax, 62
lea rax, [rax + rcx]
sar rax, 2
ret
```
down to
```asm
sub rcx, rdx
sar rcx, 2
mov rax, rcx
ret
```
(for `*const i32`)
See discussion on the `offset_to` tracking issue https://github.com/rust-lang/rust/issues/41079
Some open questions
- Would you rather I split the intrinsic PR from the library PR?
- Do we even want the safe version of the API? https://github.com/rust-lang/rust/issues/41079#issuecomment-374426786 I've added some text to its documentation that even if it's not UB, it's useless to use it between pointers into different objects.
and todos
- [x] ~~I need to make a codegen test~~ Done
- [x] ~~Can the subtraction use nsw/nuw?~~ No, it can't https://github.com/rust-lang/rust/pull/49297#discussion_r176697574
- [x] ~~Should there be `usize` variants of this, like there are now `add` and `sub` that you almost always want over `offset`? For example, I imagine `sub_ptr` that returns `usize` and where it's UB if the distance is negative.~~ Can wait for later; C gives a signed result https://github.com/rust-lang/rust/issues/41079#issuecomment-375842235, so we might as well, and this existing to go with `offset` makes sense.
adds simd_select intrinsic
The select SIMD intrinsic is used to select elements from two SIMD vectors using a mask:
```rust
let mask = b8x4::new(true, false, false, true);
let a = f32x4::new(1., 2., 3., 4.);
let b = f32x4::new(5., 6., 7., 8.);
assert_eq!(simd_select(mask, a, b), f32x4::new(1., 6., 7., 4.));
```
The number of lanes between the mask and the vectors must match, but the vector width of the mask does not need to match that of the vectors. The mask is required to be a vector of signed integers.
Note: this intrinsic will be exposed via `std::simd`'s vector masks - users are not expected to use it directly.
Since #47964 was merged, 64-bit mips started passing all structures
using 64-bit chunks regardless of their contents. The
repr-transparent-aggregates tests needs updating to cope with this.
Remove experimental -Zremap-path-prefix-from/to, and replace it with
the stabilized --remap-path-prefix=from=to variant.
This is an implementation for issue of #41555.
