| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
them.
|
|
They should at least be that, they usually warn about control flow mismatches,
and or the profile being useless, which looks like at least a warning to me.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
It destroys performance actually.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
linker commands.
See the linked LLVM reviews for the clang counter-parts.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
Executables crash in the probestack function otherwise... I haven't debugged
much further than that.
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
|
|
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.
|
|
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
|
|
Add a -Z flag for LLVM align attributes on arguments
LLVM seems to still put the assume calls in when inlining, so this probably isn't in a place where it can be turned on by default, but it's interesting to experiment with.
For example, this makes `mem::swap::<u64x8>` be 8x `vmovaps ymm` instead of 16x `vmovups xmm`, on my cpu.
|
|
fixes #48884
|
|
NLL should identify and respect the lifetime annotations that the user wrote
Part of #47184.
r? @nikomatsakis
|
|
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`)
|
|
|
|
|
|
This commit adds a new attribute to the Rust compiler specific to the wasm
target (and no other targets). The `#[wasm_import_module]` attribute is used to
specify the module that a name is imported from, and is used like so:
#[wasm_import_module = "./foo.js"]
extern {
fn some_js_function();
}
Here the import of the symbol `some_js_function` is tagged with the `./foo.js`
module in the wasm output file. Wasm-the-format includes two fields on all
imports, a module and a field. The field is the symbol name (`some_js_function`
above) and the module has historically unconditionally been `"env"`. I'm not
sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd
like the ability to configure it!
The proposed ES module integration with wasm (aka a wasm module is "just another
ES module") requires that the import module of wasm imports is interpreted as an
ES module import, meaning that you'll need to encode paths, NPM packages, etc.
As a result, we'll need this to be something other than `"env"`!
Unfortunately neither our version of LLVM nor LLD supports custom import modules
(aka anything not `"env"`). My hope is that by the time LLVM 7 is released both
will have support, but in the meantime this commit adds some primitive
encoding/decoding of wasm files to the compiler. This way rustc postprocesses
the wasm module that LLVM emits to ensure it's got all the imports we'd like to
have in it.
Eventually I'd ideally like to unconditionally require this attribute to be
placed on all `extern { ... }` blocks. For now though it seemed prudent to add
it as an unstable attribute, so for now it's not required (as that'd force usage
of a feature gate). Hopefully it doesn't take too long to "stabilize" this!
cc rust-lang-nursery/rust-wasm#29
|
|
This commit is an implementation of adding custom sections to wasm artifacts in
rustc. The intention here is to expose the ability of the wasm binary format to
contain custom sections with arbitrary user-defined data. Currently neither our
version of LLVM nor LLD supports this so the implementation is currently custom
to rustc itself.
The implementation here is to attach a `#[wasm_custom_section = "foo"]`
attribute to any `const` which has a type like `[u8; N]`. Other types of
constants aren't supported yet but may be added one day! This should hopefully
be enough to get off the ground with *some* custom section support.
The current semantics are that any constant tagged with `#[wasm_custom_section]`
section will be *appended* to the corresponding section in the final output wasm
artifact (and this affects dependencies linked in as well, not just the final
crate). This means that whatever is interpreting the contents must be able to
interpret binary-concatenated sections (or each constant needs to be in its own
custom section).
To test this change the existing `run-make` test suite was moved to a
`run-make-fulldeps` folder and a new `run-make` test suite was added which
applies to all targets by default. This test suite currently only has one test
which only runs for the wasm target (using a node.js script to use `WebAssembly`
in JS to parse the wasm output).
|
|
fix vector fmin/fmax non-fast/fast intrinsics NaN handling
This bugs shows up in release mode tests of `stdsimd`: https://github.com/rust-lang-nursery/stdsimd/pull/391 . The intrinsics are thoroughly tested there for roundoff errors, NaN, and overflow behavior.
The problem was that the non-fast intrinsics where specifying `NoNaNs == true`, which meant that they don't support NaNs. This is incorrect, the non-fast intrinsics should handle NaNs properly.
Also, the "fast" intrinsics where specifying `NoNaNs == false` which meant that they support NaNs and then fast-math, which probably disables this support. This was not intended either.
I've added a comment specifying what the boolean flags do.
|
|
r=alexcrichton
whitelist every target feature for rustdoc
When https://github.com/rust-lang-nursery/stdsimd/pull/367 was attempted to be upstreamed, it failed to document on non-x86 targets because it made every intrinsic visible, even the ones on foreign arches. This change makes it so that whenever rustdoc asks for the target feature whitelist, it gets a list of every feature known to every arch in `rustc_trans/llvm_util.rs`.
Before pushing, i temporarily updated the `stdsimd` submodule to include the `doc(cfg)` change, generated documentation for `aarch64-unknown-linux-gnu`, and it completed without a problem. The generated `core::arch` docs contained complete submodules for all main arches.
|
|
|
|
|
|
Rollup of 17 pull requests
- Successful merges: #46518, #48810, #48834, #48902, #49004, #49092, #49096, #49099, #49104, #49125, #49139, #49152, #49157, #49161, #49166, #49176, #49184
- Failed merges:
|
|
Merge `feature(advanced_slice_patterns)` into `feature(slice_patterns)`
|
|
Replace many of the last references to readmes
In particular, this removes the dep track readme, so it should not be merged before https://github.com/rust-lang-nursery/rustc-guide/pull/92
Fix #47935
cc #48478
r? @nikomatsakis
|
|
|
|
LLVM seems to still put the assume calls in when inlining, so this probably isn't in a place where it can be turned on by default, but it's interesting to experiment with.
For example, this makes `swap::<u64x8>` be 8x `vmovaps ymm` instead of 16x `vmovups xmm`, on my cpu.
|
|
Make CrateMetadata and CStore thread-safe
r? @michaelwoerister
|
|
add intrinsics for portable packed simd vector reductions
Adds the following portable vector reduction intrinsics:
* fn simd_reduce_add<T, U>(x: T) -> U;
* fn simd_reduce_mul<T, U>(x: T) -> U;
* fn simd_reduce_min<T, U>(x: T) -> U;
* fn simd_reduce_max<T, U>(x: T) -> U;
* fn simd_reduce_and<T, U>(x: T) -> U;
* fn simd_reduce_or<T, U>(x: T) -> U;
* fn simd_reduce_xor<T, U>(x: T) -> U;
I've also added:
* fn simd_reduce_all<T>(x: T) -> bool;
* fn simd_reduce_any<T>(x: T) -> bool;
These produce better code that what we are currently producing in `stdsimd`, but the code is still not optimal due to this LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=36702
r? @alexcrichton
|
|
|
|
rustc: Enable embedding LLVM bitcode for iOS
This commit updates rustc to embed bitcode in each object file generated by
default when compiling for iOS. This was determined in #35968 as a step
towards better compatibility with the iOS toolchain, so let's give it a spin and
see how it turns out!
Note that this also updates the `cc` dependency which should propagate this
change of embedding bitcode for C dependencies as well.
|
|
Rollup of 17 pull requests
- Successful merges: #48706, #48875, #48892, #48922, #48957, #48959, #48961, #48965, #49007, #49024, #49042, #49050, #48853, #48990, #49037, #49049, #48972
- Failed merges:
|
|
rustc_trans: fix small aggregate returns for big-endian mips64 FFI
Current model of threating small aggregate returns as smallest encompassing integer works only for little-endian mips64.
The patch forces small aggregate return values to be viewed as one or two i64 chunks leaving to the casting implementation
to handle endianes differences.
|
|
rustc: Add `sha` to the x86 feature whitelist
This'll help us bind the [`SHA` intrinsics][intr] in stdsimd!
[intr]: https://software.intel.com/sites/landingpage/IntrinsicsGuide/#othertechs=SHA
|
|
rustc: Start a custom cabi module for wasm32
It actually was already using the `cabi_asmjs` module but that was by accident,
so route the new `wasm32-unknown-unknown` target to a new `cabi_wasm32` module.
The first entries in this module are to use `signext` and `zeroext` for types
that are under 32 bytes in size
Closes rust-lang-nursery/rust-wasm#88
|
|
|
|
|
|
|
|
Stabilize the syntax `a..=b` and `..=b`.
|
|
Stabilize std::ops::RangeInclusive and std::ops::RangeInclusiveTo.
|
|
Stabilise feature(never_type). Introduce feature(exhaustive_patterns)
This stabilizes `!`, removing the feature gate as well as the old defaulting-to-`()` behavior. The pattern exhaustiveness checks which were covered by `feature(never_type)` have been moved behind a new `feature(exhaustive_patterns)` gate.
|
|
Current model of threating small aggregate returns as smallest encompassing integer works only for little-endian mips64.
The patch forces small aggregate return values to be viewed as one or two i64 chunks leaving to the casting implementation
to handle endianes differences.
|
|
|
|
|
|
bump mipsel isa leval and enable fpxx
This PR:
* Bumps the default ISA level of the mipsel targets to `mips32r2`. The big endian mips targets are already built with `mips32r2`. This is the usual baseline for the MIPS ISA these days used by other projects, although it does drop support for the 4K processor (which was the only processor released with mips32 r1). Debian no longer supports pre-R2 processors. Using R2 also improves code generation in FPXX in certain circumstances.
* Enables the FPXX floating point ABI[1] on 32-bit hard-float targets by default. This ABI adds some extra restrictions to the existing ABI which allows code to run on the two main floating point modes found on MIPS (FR0 and FR1) and remains compatible with the FR32 ABI currently in use. All code within an executable (including all shared libraries) must be compiled with FPXX/FP64 to be able to use MSA on 32-bit MIPS.
* Enables the "nooddspreg" feature with FPXX. This feature is usually enabled whenever FPXX is. It also helps workaround some issues on Loongson processors. I'm hoping this will fix some test failures mentioned in #39013.
* Adds the `fp64` feature to the MIPS whitelist. This feature must be enabled to use MSA on 32-bit MIPS, otherwise LLVM will complain.
[1] See https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
|
|
rustc: Don't invoke `lld` with an `@`-file
Looks like LLD doesn't support this yet, so always try to use the OS before we
fall back to using `@`
cc https://github.com/rust-lang/rust/issues/48948
|
|
Types will no longer default to `()`, instead always defaulting to `!`.
This disables the associated warning and removes the flag from TyTuple
|
