The upcoming SIMD support in the wasm target is unique from the other
platforms where it's either unconditionally available or not available,
there's no halfway where a subsection of the program can use it but no
other parts of the program can use it. In this world it's valid for wasm
SIMD args to always be passed by value and there's no need to pass them
by reference.
This commit adds a new custom target specification option
`simd_types_indirect` which defaults to `true`, but the wasm backend
disables this and sets it to `false`.
Disable the PLT where possible to improve performance
for indirect calls into shared libraries.
This optimization is enabled by default where possible.
- Add the `NonLazyBind` attribute to `rustllvm`:
This attribute informs LLVM to skip PLT calls in codegen.
- Disable PLT unconditionally:
Apply the `NonLazyBind` attribute on every function.
- Only enable no-plt when full relro is enabled:
Ensures we only enable it when we have linker support.
- Add `-Z plt` as a compiler option
Revert most of MaybeUninit, except for the new API itself
This reverts most of https://github.com/rust-lang/rust/pull/53508/ for perf reasons (first commit reverts that entire PR), except for the new API itself (added back in 2nd commit).
Use no_default_libraries for all NetBSD flavors
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close#49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close#49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
Add target thumbv7a-pc-windows-msvc
This is an early draft of support for Windows/ARM. To test it,
1. Install Visual Studio 2017 and Windows SDK version 17134.
1. Obtain alexcrichton/xz2-rs#35, rust-lang-nursery/compiler-builtins#256, and the fix for [LLVM Bug 38620](https://bugs.llvm.org/show_bug.cgi?id=38620).
2. Open a command prompt and run
```
set CC_thumbv7a-pc-windows-msvc=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\CL.exe
set CFLAGS_thumbv7a-pc-windows-msvc=/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /nologo
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc
```
It will build the stage 2 compiler, but fail building stage 2 test. To build an executable targeting windows/arm,
1. Copy `build\x86_64-pc-windows-msvc\stage0\bin\cargo.exe` to `build\x86_64-pc-windows-msvc\stage2\bin`
2. Open a command prompt and run
```
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set PATH=build\x86_64-pc-windows-msvc\stage2\bin;%PATH%
cargo new hello
cd hello
cargo build --target thumbv7a-pc-windows-msvc –release
```
Copy target\thumbv7a-pc-windows-msvc\release\hello.exe to your platform and run.
There are a number of open issues that I'm hoping to get help with:
- Error when compiling the `test` crate: `error: cannot link together two panic runtimes: panic_abort and panic_unwind`
- Warnings when building the compiler_builtins crate: `warning: cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'`. It looks like the build system is passing GCC-style flags to MSVC.
- How to specify the LIBPATH entries for ARM. Right now they are hardcoded as absolute paths in the target spec.
This pull request depends on
- alexcrichton/xz2-rs#35 - update vcxproj to Visual Studio 2017
- rust-lang-nursery/compiler-builtins#256 - fix compile errors when building for windows/arm
- [Bug 38620 - ARM: Incorrect COFF relocation type for thumb bl instruction](https://bugs.llvm.org/show_bug.cgi?id=38620)
This PR updates #52659
Fix a few AMDGPU related issues
* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
rustc: Prepare the `atomics` feature for wasm
This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!
Here there are a few inclusions:
* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
enable/disable/gate on this.
* The `singlethread` option is turned off for wasm when the `atomics` feature is
enabled. This means that by default wasm won't be lowering with atomics, but
when atomics are enabled globally we'll turn off single-threaded mode to
actually codegen atomics. This probably isn't what we'll want in the long term
but for now it should work.
* Finally the maximum atomic width is increased to 64 to reflect the current
wasm spec.
Implement the `min_const_fn` feature gate
cc @RalfJung @eddyb
r? @Centril
implements the feature gate for #53555
I added a hack so the `const_fn` feature gate also enables the `min_const_fn` feature gate. This ensures that nightly users of `const_fn` don't have to touch their code at all.
The `min_const_fn` checks are run first, and if they succeeded, the `const_fn` checks are run additionally to ensure we didn't miss anything.
This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!
Here there are a few inclusions:
* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
enable/disable/gate on this.
* The `singlethread` option is turned off for wasm when the `atomics` feature is
enabled. This means that by default wasm won't be lowering with atomics, but
when atomics are enabled globally we'll turn off single-threaded mode to
actually codegen atomics. This probably isn't what we'll want in the long term
but for now it should work.
* Finally the maximum atomic width is increased to 64 to reflect the current
wasm spec.
add more Cortex-R targets
This expands on PR #53663 to complete the set of Cortex-R targets and builds
rust-std components for them.
r? @alexcrichton
each extra rust-std component (there's 4 of them) takes about 3 minutes to build
on my local machine. In terms of stability (LLVM codegen bugs) these new targets
should be as stable as the Cortex-M ones (e.g. `thumbv7m-none-eabi`).
If the extra build time is too much we can leave the rust-std components out for
now
closes#53663
cc @paoloteti
Similar to `armebv7r-none-eabihf`, but for Little-endian MCUs.
As example TI RM4x/RM5x are Little-endian Cortex-R4F/R5F MCUs.
CI/Dockerfile is intentionally in the disabled folder.
try to infer linker flavor from linker name and vice versa
This is a second take on PR #50359 that implements the logic proposed in https://github.com/rust-lang/rust/pull/50359#pullrequestreview-116663121
With this change it would become possible to link `thumb*` binaries using GNU's LD on stable as `-C linker=arm-none-eabi-ld` would be enough to change both the linker and the linker flavor from their default values of `arm-none-eabi-gcc` and `gcc`.
To link `thumb*` binaries using rustc's LLD on stable `-Z linker-flavor` would need to be stabilized as `-C linker=rust-lld -Z linker-flavor=ld.lld` are both required to change the linker and the linker flavor, but this PR doesn't propose that. We would probably need some sort of stability guarantee around `rust-lld`'s name and availability to make linking with rustc's LLD truly stable.
With this change it would also be possible to link `thumb*` binaries using a system installed LLD on stable using the `-C linker=ld.lld` flag (provided that `ld.lld` is a symlink to the system installed LLD).
r? @alexcrichton
