| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
We use a new MemFlags bitflags type to merge some store code paths.
|
|
Fixes #50371.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce a TargetTriple enum to support absolute target paths
This PR replaces target triple strings with a `TargetTriple` enum, which represents either a target triple or a path to a JSON target file. The path variant is used if the `--target` argument has a `.json` extension, else the target triple variant is used.
The motivation of this PR is support for absolute target paths to avoid the need for setting the `RUST_TARGET_PATH` environment variable (see rust-lang/cargo#4905 for more information). For places where some kind of triple is needed (e.g. in the sysroot folder), we use the file name (without extension).
For compatibility, we keep the old behavior of searching for a file named `$(target_triple).json` in `RUST_TARGET_PATH` for non-official target triples.
|
|
|
|
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.
|
|
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.
|
|
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
|
|
Types will no longer default to `()`, instead always defaulting to `!`.
This disables the associated warning and removes the flag from TyTuple
|
|
In particular:
- `fully_normalize_monormophic_ty` => `normalize_erasing_regions`
- `normalize_associated_type_in_env` => `normalize_erasing_regions`
- `fully_normalize_associated_types_in` => `normalize_erasing_regions`
- `erase_late_bound_regions_and_normalize` => `normalize_erasing_late_bound_regions`
|
|
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
|
|
|
|
|
|
|
|
|
|
This commit changes the ABI of SIMD types in the "Rust" ABI to unconditionally
be passed via pointers instead of being passed as immediates. This should fix a
longstanding issue, #44367, where SIMD-using programs ended up showing very odd
behavior at runtime because the ABI between functions was mismatched.
As a bit of a recap, this is sort of an LLVM bug and sort of an LLVM feature
(today's behavior). LLVM will generate code for a function solely looking at the
function it's generating, including calls to other functions. Let's then say
you've got something that looks like:
```llvm
define void @foo() { ; no target features enabled
call void @bar(<i64 x 4> zeroinitializer)
ret void
}
define void @bar(<i64 x 4>) #0 { ; enables the AVX feature
...
}
```
LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo`
doesn't have access to these registers. Instead it's generated with emulation
that uses two 128-bit registers. The `bar` function, on the other hand, will
expect its argument in an AVX register (as it has AVX enabled). This means we've
got a codegen problem!
Comments on #44367 have some more contexutal information but the crux of the
issue is that if we want SIMD to work in general we'll need to ensure that
whenever a function calls another they ABI of the arguments being passed is in
agreement.
One possible solution to this would be to insert "shim functions" where whenever
a `target_feature` mismatch is detected the compiler inserts a shim function
where you pass arguments via memory to the shim and then the shim loads the
values and calls the target function (where the shim and the target have the
same target features enabled). This unfortunately is quite nontrivial to
implement in rustc today (especially when accounting for function pointers and
such).
This commit takes a different solution, *always* passing SIMD arguments through
memory instead of passing as immediates. This strategy solves the problem at the
LLVM layer because the ABI between two functions never uses SIMD registers. This
also shouldn't be a hit to performance because SIMD performance is thought to
often rely on inlining anyway, where a `call` instruction, even if using SIMD
registers, would be disastrous to performance regardless. LLVM should then be
more than capable of fixing all our memory usage to use registers instead after
enough inlining has been performed.
Note that there's a few caveats to this commit though:
* The "platform intrinsic" ABI is omitted from "always pass via memory". This
ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc
need to have the arguments as an immediate.
* Additionally this commit does *not* fix the `extern` ("C") ABI. This means
that the bug in #44367 can still happen when using non-Rust-ABI functions. My
hope is that before stabilization we can ban and/or warn about SIMD types in
these functions (as AFAIK there's not much motivation to belong there anyway),
but I'll leave that for a later commit and if this is merged I'll file a
follow-up issue.
All in all this...
Closes #44367
|
|
Closes #47278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
