The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers](https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt) which can be used to perform atomic operations. When linked with `libc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics.
As this target is specifically `linux` and `gnueabi`, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all.
I have used this change in a custom target (along with `xargo`) to build `std`, as well as a number of higher level crates.
Mir pretty print: Add cleanup comment
I found it useful to add a comment indicating whether or not a
BasicBlock is a cleanup block or not. Hopefully you'll find it
useful too.
Docs for size_of::<#[repr(C)]> items.
Most of this info comes from camlorn's blog post on optimizing struct layout and the Rustonomicon.
I don't really like my wording in the first paragraph.
I also cannot find a definition of what `#[repr(C)]` does for enums that have variants with fields. They're allowed, unlike `#[repr(C)] enum`s with no variants.
Fix native main() signature on 64bit
Hello,
in LLVM-IR produced by rustc on x86_64-linux-gnu, the native main() function had incorrect types for the function result and argc parameter: i64, while it should be i32 (really c_int). See also #20064, #29633.
So I've attempted a fix here. I tested it by checking the LLVM IR produced with --target x86_64-unknown-linux-gnu and i686-unknown-linux-gnu. Also I tried running the tests (`./x.py test`), however I'm getting two failures with and without the patch, which I'm guessing is unrelated.
Update the libcompiler_builtins submodule
Pulls in the latest changes from libcompiler_builtins.
It should work, but it would be best if this wouldn't get put into a rollup so that bisecting is possible if there is a regression.
r? @alexcrichton
Docs: Add trace_macros! to unstable book
As TIL'd at Rustfest :)
Note: This is unfortunately untested, since I'm on my laptop battery, and compiling LLVM would probably eat at least 50% of it on my dual core CPU. (Is there a way to build docs without compiling LLVM?)
rustc: Enable LTO and multiple codegen units
This commit is a refactoring of the LTO backend in Rust to support compilations
with multiple codegen units. The immediate result of this PR is to remove the
artificial error emitted by rustc about `-C lto -C codegen-units-8`, but longer
term this is intended to lay the groundwork for LTO with incremental compilation
and ultimately be the underpinning of ThinLTO support.
The problem here that needed solving is that when rustc is producing multiple
codegen units in one compilation LTO needs to merge them all together.
Previously only upstream dependencies were merged and it was inherently relied
on that there was only one local codegen unit. Supporting this involved
refactoring the optimization backend architecture for rustc, namely splitting
the `optimize_and_codegen` function into `optimize` and `codegen`. After an LLVM
module has been optimized it may be blocked and queued up for LTO, and only
after LTO are modules code generated.
Non-LTO compilations should look the same as they do today backend-wise, we'll
spin up a thread for each codegen unit and optimize/codegen in that thread. LTO
compilations will, however, send the LLVM module back to the coordinator thread
once optimizations have finished. When all LLVM modules have finished optimizing
the coordinator will invoke the LTO backend, producing a further list of LLVM
modules. Currently this is always a list of one LLVM module. The coordinator
then spawns further work to run LTO and code generation passes over each module.
In the course of this refactoring a number of other pieces were refactored:
* Management of the bytecode encoding in rlibs was centralized into one module
instead of being scattered across LTO and linking.
* Some internal refactorings on the link stage of the compiler was done to work
directly from `CompiledModule` structures instead of lists of paths.
* The trans time-graph output was tweaked a little to include a name on each
bar and inflate the size of the bars a little
The innermost type is not [u8] on all platforms but is assumed to have
the same memory layout as [u8] since this conversion was done via
mem::transmute before.
