| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Specifically, remove both `-Z no_integrated_as` and
`TargetOptions::no_integrated_as`. The latter was only used for the
`msp430_none_elf` platform, for which it's no longer required.
|
|
It makes things a little clearer.
|
|
Currently, there are three fields in `ModuleConfig` that dictate
how object files are emitted: `emit_obj`, `obj_is_bitcode`, and
`embed_bitcode`.
Some of the combinations of these fields are nonsensical, in particular
having both `obj_is_bitcode` and `embed_bitcode` true at the same time.
Also, currently:
- we needlessly emit and then delete a bytecode file if `obj_is_bitcode`
is true but `emit_obj` is false;
- we needlessly embed bitcode in the LLVM module if `embed_bitcode` is
true and `emit_obj` is false.
This commit combines the three fields into one, with a new type
`EmitObj` (and the auxiliary `BitcodeSection`) which can encode five
different possibilities.
In the old code, `set_flags` would set `obj_is_bitcode` and
`embed_bitcode` on all three of the configs (`modules`, `allocator`,
`metadata`) if the relevant other conditions were met, even if no object
code needed to be emitted for one or more of them. Whereas
`start_async_codegen` would set `emit_obj`, but only for those configs
that need it.
In the new code, `start_async_codegen` does all the work of setting
`emit_obj`, and it only does that for the configs that need it.
`set_flags` no longer sets anything related to object file emission.
|
|
Refactor `codegen`
`codegen` in `src/librustc_codegen_llvm/back/write.rs` is long and has complex control flow. These commits refactor it and make it easier to understand.
|
|
|
|
This adds a missing `!config.obj_is_bitcode` condition to two places
that should have it.
As a result, when `obj_is_bitcode` and `no_integrated_as` are both true,
the compiler will no longer unnecessarily emit asm, convert it to an
object file, and then overwrite that object file with bitcode.
|
|
|
|
|
|
Because the `(true, true)` combination isn't valid.
|
|
I find the code easier to read if the values in `config` are all used
directly, rather than a mix of `config` values and local variables. It
will also faciliate some of the following commits.
Also, use `config.bitcode_needed()` in one place.
|
|
|
|
|
|
|
|
anything.
For example: `if let Some(_) = foo() {}` can be reduced to `if foo().is_some() {}` (clippy::redundant_pattern_matching)
|
|
use is_empty() instead of len() == x to determine if structs are empty.
|
|
|
|
|
|
|
|
The new pass manager can be enabled using
-Z new-llvm-pass-manager=on.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
adopts simple strategy devised with assistance from mw: Instead of accumulating
(and acting upon) LTO import information over an unbounded number of prior
compilations, just see if the current import set matches the previous import set.
if they don't match, then you cannot reuse the PostLTO build product for that
module.
In either case (of a match or a non-match), we can (and must) unconditionally
emit the current import set as the recorded information in the incremental
compilation cache, ready to be loaded during the next compiler run for use in
the same check described above.
resolves issue 59535.
|
|
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.
Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).
The end results of this change are:
* Rustbuild's build process for the compiler as all the "oh don't forget
the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
parallelism in the main rustc build step rather than splitting
`librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
multiple codegen backends is still supported, and dynamic loading of a
codegen backend is still supported.
|
|
Migrate to LLVM{Get,Set}ValueName2
The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
Closes #64223.
r? @rkruppe
|
|
Use Module::print() instead of a PrintModulePass
llvm::Module has a print() method. It is unnecessary to create a pass just for the purpose of printing LLVM IR.
|
|
The deprecated `LLVM{Get,Set}ValueName` only work with NUL-terminated
strings, but the `2` variants use explicit lengths, which fits better
with Rust strings and slices. We now use these in new helper functions
`llvm::{get,set}_value_name` that convert to/from `&[u8]`.
|
|
Change Linker for x86_64-fortanix-unknown-sgx target to rust-lld
Changed linker for `x86_64-fortanix-unknown-sgx` target to `rust-lld`
This change needed the RelaxELFRelocations flag to be set for it to work correctly
r? @jethrogb
|
|
|
|
For SGX, the relocation using the relocation table is done by
the code in rust/src/libstd/sys/sgx/abi/reloc.rs and this code
should not require relocation. Setting RelaxELFRelocations flag
if allows this to happen, hence adding a Target Option for it.
|
|
llvm::Module has a print() method. It is unnecessary to create a
pass just for the purpose of printing LLVM IR.
|
|
|
|
LLVM exposes a C API `LLVMAddAnalysisPasses` and hence Rust's own
wrapper `LLVMRustAddAnalysisPasses` is not needed anymore.
|
|
|
|
|
|
|
|
|
|
davidtwco:issue-19834-improper-ctypes-in-extern-C-fn, r=rkruppe"
This reverts commit 3f0e16473de5ec010f44290a8c3ea1d90e0ad7a2, reversing
changes made to 61a551b4939ec1d5596e585351038b8fbd0124ba.
|
|
r=rkruppe
improper_ctypes: `extern "C"` fns
cc #19834. Fixes #65867.
This pull request implements the change [described in this comment](https://github.com/rust-lang/rust/issues/19834#issuecomment-466671572).
cc @rkruppe @varkor @shepmaster
|
|
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
This addresses #65024, as it allows RISC-V target specification
files to set "llvm-abiname": "lp64d". In general, it is useful
for the programmer to be able to set this codegen parameter,
which other languages usually expose under a compiler argument
like "-mabi=<XYZ>".
|
|
Fix #64153
This PR changes how the compiler detects if an object file from an upstream crate is a Rust object file or not. Instead of checking if the name starts with the crate name and ends with `.o` (which is not always the case, as described in #64153), it now just checks if the filename ends with `.rcgu.o`.
This fixes #64153. However, ideally we'd clean up the code around filename generation some more. Then this check could be made more robust.
r? @alexcrichton
|
|
generated object files.
|
