rust/src/rustllvm/RustWrapper.cpp, branch 1.8.0

Add intrinsics for compare_exchange and compare_exchange_weak

2016-02-18T19:07:05+00:00

Auto merge of #30962 - Amanieu:non_volatile_atomic, r=alexcrichton

2016-02-04T02:46:44+00:00

Rust currently emits atomic loads and stores with the LLVM `volatile` qualifier. This is unnecessary and prevents LLVM from performing optimization on these atomic operations.

trans: Reimplement unwinding on MSVC

2016-01-30T00:25:20+00:00

This commit transitions the compiler to using the new exception handling instructions in LLVM for implementing unwinding for MSVC. This affects both 32 and 64-bit MSVC as they're both now using SEH-based strategies. In terms of standard library support, lots more details about how SEH unwinding is implemented can be found in the commits. In terms of trans, this change necessitated a few modifications: * Branches were added to detect when the old landingpad instruction is used or the new cleanuppad instruction is used to `trans::cleanup`. * The return value from `cleanuppad` is not stored in an `alloca` (because it cannot be). * Each block in trans now has an `Option` instead of `is_lpad: bool` for indicating whether it's in a landing pad or not. The new exception handling intrinsics require that on MSVC each `call` inside of a landing pad is annotated with which landing pad that it's in. This change to the basic block means that whenever a `call` or `invoke` instruction is generated we know whether to annotate it as part of a cleanuppad or not. * Lots of modifications were made to the instruction builders to construct the new instructions as well as pass the tagging information for the call/invoke instructions. * The translation of the `try` intrinsics for MSVC has been overhauled to use the new `catchpad` instruction. The filter function is now also a rustc-generated function instead of a purely libstd-defined function. The libstd definition still exists, it just has a stable ABI across architectures and leaves some of the really weird implementation details to the compiler (e.g. the `localescape` and `localrecover` intrinsics).

trans: Upgrade LLVM

2016-01-30T00:25:20+00:00

This brings some routine upgrades to the bundled LLVM that we're using, the most notable of which is a bug fix to the way we handle range asserts when loading the discriminant of an enum. This fix ended up being very similar to f9d4149c where we basically can't have a range assert when loading a discriminant due to filling drop, and appropriate flags were added to communicate this to `trans::adt`.

Don't make atomic loads and stores volatile

2016-01-16T20:16:10+00:00

rustllvm: Update to LLVM trunk

2015-10-24T09:42:23+00:00

Tweak Travis to use GCE

2015-09-29T23:56:35+00:00

Travis CI has new infrastructure using the Google Compute Engine which has both faster CPUs and more memory, and we've been encouraged to switch as it should help our build times! The only downside currently, however, is that IPv6 is disabled, causing a number of standard library tests to fail. Consequently this commit tweaks our travis config in a few ways: * ccache is disabled as it's not working on GCE just yet * Docker is used to run tests inside which reportedly will get IPv6 working * A system LLVM installation is used instead of building LLVM itself. This is primarily done to reduce build times, but we want automation for this sort of behavior anyway and we can extend this in the future with building from source as well if needed. * gcc-specific logic is removed as the docker image for Ubuntu gives us a recent-enough gcc by default.

trans: Move rust_try into the compiler

2015-07-21T23:08:11+00:00

This commit moves the IR files in the distribution, rust_try.ll, rust_try_msvc_64.ll, and rust_try_msvc_32.ll into the compiler from the main distribution. There's a few reasons for this change: * LLVM changes its IR syntax from time to time, so it's very difficult to have these files build across many LLVM versions simultaneously. We'll likely want to retain this ability for quite some time into the future. * The implementation of these files is closely tied to the compiler and runtime itself, so it makes sense to fold it into a location which can do more platform-specific checks for various implementation details (such as MSVC 32 vs 64-bit). * This removes LLVM as a build-time dependency of the standard library. This may end up becoming very useful if we move towards building the standard library with Cargo. In the immediate future, however, this commit should restore compatibility with LLVM 3.5 and 3.6.

rustc_trans: Update LLVMBuildLandingPad signature

2015-07-17T03:25:51+00:00

The C API of this function changed so it no longer takes a personality function. A shim was introduced to call the right LLVM function (depending on which version we're compiled against) to set the personality function on the outer function. The compiler only ever sets one personality function for all generated functions, so this should be equivalent.

trans: Use LLVM's writeArchive to modify archives

2015-07-10T16:06:21+00:00

We have previously always relied upon an external tool, `ar`, to modify archives that the compiler produces (staticlibs, rlibs, etc). This approach, however, has a number of downsides: * Spawning a process is relatively expensive for small compilations * Encoding arguments across process boundaries often incurs unnecessary overhead or lossiness. For example `ar` has a tough time dealing with files that have the same name in archives, and the compiler copies many files around to ensure they can be passed to `ar` in a reasonable fashion. * Most `ar` programs found do **not** have the ability to target arbitrary platforms, so this is an extra tool which needs to be found/specified when cross compiling. The LLVM project has had a tool called `llvm-ar` for quite some time now, but it wasn't available in the standard LLVM libraries (it was just a standalone program). Recently, however, in LLVM 3.7, this functionality has been moved to a library and is now accessible by consumers of LLVM via the `writeArchive` function. This commit migrates our archive bindings to no longer invoke `ar` by default but instead make a library call to LLVM to do various operations. This solves all of the downsides listed above: * Archive management is now much faster, for example creating a "hello world" staticlib is now 6x faster (50ms => 8ms). Linking dynamic libraries also recently started requiring modification of rlibs, and linking a hello world dynamic library is now 2x faster. * The compiler is now one step closer to "hassle free" cross compilation because no external tool is needed for managing archives, LLVM does the right thing! This commit does not remove support for calling a system `ar` utility currently. We will continue to maintain compatibility with LLVM 3.5 and 3.6 looking forward (so the system LLVM can be used wherever possible), and in these cases we must shell out to a system utility. All nightly builds of Rust, however, will stop needing a system `ar`.