| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Even if that is just happening because of `abort_if_errors`
|
|
This reverts commit 2c5cd9ce53d2d25041db0cb02b40ba460ffa8908.
|
|
|
|
Disable LLVM verification by default
Currently -Z no-verify only controls IR verification prior to LLVM codegen, while verification is performed unconditionally both before and after linking with (Thin)LTO.
Also wondering what the sentiment is on disabling verification by default (and e.g. only enabling it on ALT builds with assertions). This does not seem terribly useful outside of rustc development and it does seem to show up in profiles (at something like 3%).
**EDIT:** A table showing the various configurations and what is enabled when.
| Configuration | Dynamic verification performed | LLVM static assertions compiled in |
| --- | --- | --- |
| alt builds | | yes |
| nightly builds | | no |
| stable builds | | no |
| CI builds | | |
| dev builds in a checkout | | |
|
|
Fix rustdoc run failures by shutting down definitely some lints
Fixes #51661.
cc @oli-obk @arielb1 @eddyb
|
|
When doing linker-plugin based LTO, write LLVM bitcode obj-files instead of embedding the bitcode into the regular object file.
This PR makes the compiler emit LLVM bitcode object files instead of regular object files with the IR embed when compiling for linker-plugin-based LTO. The reasoning for switching the strategy is this:
- Embedding bitcode in a section of the object file actually makes us save bitcode twice in rlibs and Rust dylibs, once for linker-based LTO and once for rustc-based LTO. That's a waste of space.
- When compiling for plugin-based LTO, one usually has no use for the machine code also present in the object file. Generating it is a waste of time.
- When compiling for plugin-based LTO, `rustc` will skip running ThinLTO because the linker will do that anyway. This has the side effect of then generating poorly optimized machine code, which makes it even less useful (and may lead to users not knowing why their code is slow instead of getting an error).
- Not having machine code available makes it impossible for the linker to silently fall back to not inlining stuff across language boundaries.
- This is what Clang does and according to [the documentation](https://llvm.org/docs/BitCodeFormat.html#native-object-file-wrapper-format) is the better supported option.
- The current behavior (minus the runtime performance problems) is still available via `-Z embed-bitcode` (we might want to do this for `libstd` at some point).
r? @alexcrichton
|
|
fix typo in stable `--edition` error message
(diff is self-explanatory)
|
|
|
|
instead of embedding the bitcode into the regular object file.
|
|
enable Atomic*.{load,store} for ARMv6-M / MSP430
closes #45085
as proposed in https://github.com/rust-lang/rust/issues/45085#issuecomment-384825434
this commit adds an `atomic_cas` target option and extends the `#[cfg(target_has_atomic)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
r? @alexcrichton
|
|
rustc: Update tracking issue for wasm_import_module
It's now https://github.com/rust-lang/rust/issues/52090
|
|
|
|
[cross-lang-lto] Allow the linker to choose the LTO-plugin (which is useful when using LLD)
This PR allows for not specifying an LTO-linker plugin but still let `rustc` invoke the linker with the correct plugin arguments. This is useful when using LLD which does not need the `-plugin` argument. Since LLD is the best linker for this scenario anyway, this change should improve ergonomics quite a bit.
r? @alexcrichton
|
|
Add command line lint manipulation in rustdoc
Fixes #50082.
r? @QuietMisdreavus
|
|
|
|
closes #45085
this commit adds an `atomic_cas` target option and an unstable `#[cfg(target_has_atomic_cas)]`
attribute to enable a subset of the `Atomic*` API on architectures that don't support atomic CAS
natively, like MSP430 and ARMv6-M.
|
|
|
|
|
|
|
|
|
|
This disables IR verification by default.
|
|
|
|
Rebase of #50783 has accidentally revived the flag (which should be
renamed to `-Z codegen-time-graph` by #50615).
|
|
|
|
|
|
Also, turn on ReadForMatch emission by default (when using NLL).
|
|
Now, if you pass `-Z disable-ast-check-for-mutation-in-guard`, then we
will just allow you to mutably-borrow and assign in guards of `match`
arms.
This is wildly unsound with AST-borrowck. It is also unsound with
MIR-borrowck without further adjustments, which come in later in the
commit series on this Pull Request.
See also rust-lang/rust#24535 and rust-lang/rfcs#1006.
|
|
|
|
Codegen issues commonly only manifest under specific circumstances,
e.g. if multiple codegen units are used and ThinLTO is enabled.
However, these configuration are threaded, making the use of LLVM
debugging facilities hard, as output is interleaved.
This patch adds a -Z no-parallel-llvm flag, which allows disabling
parallelization of codegen and linking, while otherwise preserving
behavior with regard to codegen units and LTO.
|
|
|
|
stabilize opt-level={s,z}
closes #35784
closes #47651
### Rationale
Since the lastest LLVM upgrade rustc / LLVM does more agressive loop unrolling. This results in increased binary size of embedded / no_std programs: a hundreds of bytes increase, or about a 7x increase, in the case of the smallest Cortex-M binary cf. #49260.
As we are shooting for embedded Rust on stable it would be great to also provide a way to optimize for size (which is pretty important for embedded applications that target resource constrained devices) on stable.
Also this has been baking in nightly for a long time.
r? @alexcrichton which team has to sign off this?
|
|
This used to be disabled due to LLVM bugs in the handling of
noalias information in conjunction with unwinding. However,
according to #31681 all known LLVM bugs have been fixed by
LLVM 6.0, so it's probably time to reenable this optimization.
Noalias annotations will not be emitted by default if either
-C panic=abort (as previously) or LLVM >= 6.0 (new).
-Z mutable-noalias=no is left as an escape-hatch to allow
debugging problems suspected to stem from this change.
|
|
|
|
|
|
|
|
|
|
Add some groundwork for cross-language LTO.
Implements part of #49879:
- Adds a `-Z cross-lang-lto` flag to rustc
- Makes sure that bitcode is embedded in object files if the flag is set.
This should already allow for using cross language LTO for staticlibs (where one has to invoke the linker manually anyway). However, `rustc` will not try to enable LTO for its own linker invocations yet.
r? @alexcrichton
|
|
|
|
|
|
|
|
This reworks the force-frame-pointer PR to explicitly only consider the
value of the flag if it is provided, and use a target default otherwise.
Something that was tried but not kept was renaming the flag to
`frame-pointer`, because for flag `frame-pointer=no`, there is no
guarante, that LLVM will elide *all* the frame pointers; oposite of what
the literal reading of the flag would suggest.
|
|
We apparently used to generate bad/incomplete debug info causing
debuggers not to find symbols of stack allocated variables. This was
somehow worked around by having frame pointers.
With the current codegen, this seems no longer necessary, so we can
remove the code that force-enables frame pointers whenever debug info
is requested.
Since certain situations, like profiling code profit from having frame
pointers, we add a -Cforce-frame-pointers flag to always enable frame
pointers.
Fixes #11906
|
|
Use enum for approximate suggestions
r? @nrc @killercup
|
|
closes #35784
|
|
|
|
|
|
|
|
make rustdoc test follow the jobserver limit of threads
fix that to many threads is executing at the same time
when rustdoc test is executed.
|
|
|
