| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
rustc_llvm: adapt to flattened CLI args in LLVM
This changed in
llvm/llvm-project@e190d074a0a77c9f8a7d7938a8187a7e2076e290. I decided to stick with more duplication between the ifdef blocks to make the code easier to read for the next two years before we can plausibly drop LLVM 19.
`@rustbot` label: +llvm-main
try-job: x86_64-msvc
|
|
|
|
|
|
Revert #129749 to fix segfault in LLVM
This reverts commit 8c7a7e346be4cdf13e77ab4acbfb5ade819a4e60, reversing changes made to a00bd75b6c5c96d0a35afa2dc07ce3155112d278.
Reported in https://github.com/rust-lang/rust/pull/129749#issuecomment-2354417960. `@nikic's` theory is that the LLVM API changed in a way that makes it impossible to use concurrently from multiple threads (https://github.com/llvm/llvm-project/pull/106427#issuecomment-2354783802). I pinged `@krasimirgg` who was fine with reverting.
r? `@rust-lang/wg-llvm`
|
|
This reverts commit 8c7a7e346be4cdf13e77ab4acbfb5ade819a4e60, reversing
changes made to a00bd75b6c5c96d0a35afa2dc07ce3155112d278.
|
|
|
|
This changed in
llvm/llvm-project@e190d074a0a77c9f8a7d7938a8187a7e2076e290. I decided to
stick with more duplication between the ifdef blocks to make the code
easier to read for the next two years before we can plausibly drop LLVM
19.
@rustbot label: +llvm-main
|
|
llvm/llvm-project@2ae968a0d9fb61606b020e898d884c82dd0ed8b5
Just a simple header move.
@rustbot label: +llvm-main
|
|
llvm-wrapper: adapt for LLVM API changes
No functional changes intended.
Updates the wrapper for https://github.com/5c4lar/llvm-project/commit/21eddfac3d75879b3e0b09c5bc848526dcab6ab0.
````@rustbot```` label: +llvm-main
r? ````@nikic````
|
|
Add `-Zlint-llvm-ir`
This flag is similar to `-Zverify-llvm-ir` and allows us to lint the generated IR.
r? compiler
|
|
Updates the wrapper for https://github.com/5c4lar/llvm-project/commit/21eddfac3d75879b3e0b09c5bc848526dcab6ab0.
|
|
|
|
No functional changes intended.
Adapts llvm-wrapper for the LLVM commits https://github.com/llvm/llvm-project/commit/0f22d47a7a1f70ec77ea8ccdf08a6487827937db and https://github.com/llvm/llvm-project/commit/d6d8243dcd4ea768549904036ed31b8e59e14c73.
|
|
Since this codegen flag now only controls LLVM-generated comments rather than
all assembly comments, make the name more accurate (and also match Clang).
|
|
|
|
|
|
|
|
If we don't do this, some versions of LLVM (at least 17, experimentally)
will double-emit some error messages, which is how I noticed this. Given
that it seems to be costing some extra work, let's only request the
summary bitcode production if we'll actually bother writing it down,
otherwise skip it.
|
|
Typical uses of ThinLTO don't have any use for this as a standalone
file, but distributed ThinLTO uses this to make the linker phase more
efficient. With clang you'd do something like `clang -flto=thin
-fthin-link-bitcode=foo.indexing.o -c foo.c` and then get both foo.o
(full of bitcode) and foo.indexing.o (just the summary or index part of
the bitcode). That's then usable by a two-stage linking process that's
more friendly to distributed build systems like bazel, which is why I'm
working on this area.
I talked some to @teresajohnson about naming in this area, as things
seem to be a little confused between various blog posts and build
systems. "bitcode index" and "bitcode summary" tend to be a little too
ambiguous, and she tends to use "thin link bitcode" and "minimized
bitcode" (which matches the descriptions in LLVM). Since the clang
option is thin-link-bitcode, I went with that to try and not add a new
spelling in the world.
Per @dtolnay, you can work around the lack of this by using `lld
--thinlto-index-only` to do the indexing on regular .o files of
bitcode, but that is a bit wasteful on actions when we already have all
the information in rustc and could just write out the matching minimized
bitcode. I didn't test that at all in our infrastructure, because by the
time I learned that I already had this patch largely written.
|
|
|
|
@rustbot label: +llvm-main
|
|
C++ style guides I am aware of recommend specifically preferring = syntax
for any classes with fairly obvious constructors[^0] that do not perform
any complicated logic in their constructor. I contend that all constructors
that the `rustc_llvm` code uses qualify. This has only become more common
since C++ 17 guaranteed many cases of copy initialization elision.
The other detail is that I tried to ask another contributor with
infinitely more C++ experience than me (i.e. any) what this constructor
syntax was, and they thought it was a macro. I know of no other language
that has adopted this same syntax. As the rustc codebase features many
contributors experienced in many other languages, using a less...
unique... style has many other benefits in making this code more
lucid and maintainable, which is something it direly needs.
[^0]: e.g. https://abseil.io/tips/88
|
|
Adds initial support for DataFlowSanitizer to the Rust compiler. It
currently supports `-Zsanitizer-dataflow-abilist`. Additional options
for it can be passed to LLVM command line argument processor via LLVM
arguments using `llvm-args` codegen option (e.g.,
`-Cllvm-args=-dfsan-combine-pointer-labels-on-load=false`).
|
|
Update to LLVM 18
LLVM 18 final is planned to be released on Mar 5th. Rust 1.78 is planned to be released on May 2nd.
Tested images: dist-x86_64-linux, dist-s390x-linux, dist-aarch64-linux, dist-riscv64-linux, dist-loongarch64-linux, dist-x86_64-freebsd, dist-x86_64-illumos, dist-x86_64-musl, x86_64-linux-integration, test-various, armhf-gnu, i686-msvc, x86_64-msvc, i686-mingw, x86_64-mingw, x86_64-apple-1, x86_64-apple-2, dist-aarch64-apple
r? `@ghost`
|
|
This method is now available in upstream LLVM \o/
|
|
llvm/llvm-project@93cdd1b5cfa3735c599949b77e24dbfbe570441a
Should be no functional change.
@rustbot label: +llvm-main
|
|
|
|
effectively reverts https://github.com/rust-lang/rust/commit/9a8acea78355b604dbeb29bc38bd4dbf7bfce95f
|
|
This reverts commit 8c2b57721728233e074db69d93517614de338055, reversing
changes made to 9cf18e98f82d85fa41141391d54485b8747da46f.
|
|
|
|
Use the LLVM option NoTrapAfterNoreturn
Use this LLVM option: https://llvm.org/doxygen/classllvm_1_1TargetOptions.html#acd83fce25de1ac9f6c975135a8235c22 when TrapUnreachable is enabled. This prevents codegenning unnecessary double-traps in some situations.
See further discussion here: https://github.com/rust-lang/compiler-team/issues/618
|
|
LLVM commit https://github.com/llvm/llvm-project/commit/f09cf34d00625e57dea5317a3ac0412c07292148 moved some functions to a different header:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/24416#018c5de6-b9c9-4b22-9473-6070d99dcfa7/233-537
|
|
LLVM commit https://github.com/llvm/llvm-project/commit/1d608fc755a3e15d0020f61c9535c9b730ab9dec
renamed the pass.
|
|
Currently LLVM uses emutls by default
for some targets (such as android, openbsd),
but rust does not use it, because `has_thread_local` is false.
This commit has some changes to allow users to enable emutls:
1. add `-Zhas-thread-local` flag to specify
that std uses `#[thread_local]` instead of pthread key.
2. when using emutls, decorate symbol names
to find thread local symbol correctly.
3. change `-Zforce-emulated-tls` to `-Ztls-model=emulated`
to explicitly specify whether to generate emutls.
|
|
Restore `#![no_builtins]` crates participation in LTO.
After #113716, we can make `#![no_builtins]` crates participate in LTO again.
`#![no_builtins]` with LTO does not result in undefined references to the error. I believe this type of issue won't happen again.
Fixes #72140. Fixes #112245. Fixes #110606. Fixes #105734. Fixes #96486. Fixes #108853. Fixes #108893. Fixes #78744. Fixes #91158. Fixes https://github.com/rust-lang/cargo/issues/10118. Fixes https://github.com/rust-lang/compiler-builtins/issues/347.
The `nightly-2023-07-20` version does not always reproduce problems due to changes in compiler-builtins, core, and user code. That's why this issue recurs and disappears.
Some issues were not tested due to the difficulty of reproducing them.
r? pnkfelix
cc `@bjorn3` `@japaric` `@alexcrichton` `@Amanieu`
|
|
Update the minimum external LLVM to 16.
With this change, we'll have stable support for LLVM 16 and 17.
For reference, the previous increase to LLVM 15 was #114148
[Relevant zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/riscv.20forced-atomics)
|
|
|
|
|
|
|
|
Use the LLVM option NoTrapAfterNoreturn: https://llvm.org/doxygen/classllvm_1_1TargetOptions.html#acd83fce25de1ac9f6c975135a8235c22
when TrapUnreachable is enabled. This prevents codegenning unnecessary
double-traps in some situations.
Also, ensure NoTrapAfterNoreturn is set to false when targeting WebAssembly,
as it is known to cause bugs.
|
|
We have to preserve the symbols of the built-in functions during LTO.
|
|
When building with LTO, builtin functions that are defined but whose calls have not been inserted yet, get internalized.
We need to prevent these symbols from being internalized at LTO time.
Refer to https://reviews.llvm.org/D49434.
|
|
After applying no_builtins to the function attributes, we can remove the
DisableSimplifyLibCalls parameter.
|
|
|
|
|
|
No functional changes intended.
Adapts the wrapper for https://github.com/llvm/llvm-project/commit/0a1aa6cda2758b0926a95f87d39ffefb1cb90200.
Found by our experimental rust + llvm @ head CI: https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/22301#018a9926-a810-4e56-8ac2-e6f30b78f433/253-551
|
|
debuginfo: add compiler option to allow compressed debuginfo sections
LLVM already supports emitting compressed debuginfo. In debuginfo=full builds, the debug section is often a large amount of data, and it typically compresses very well (3x is not unreasonable.) We add a new knob to allow debuginfo to be compressed when the matching LLVM functionality is present. Like clang, if a known-but-disabled compression mechanism is requested, we disable compression and emit uncompressed debuginfo sections.
The API is different enough on older LLVMs we just pretend the support
is missing on LLVM older than 16.
|
|
lto: load bitcode sections by name
Upstream change
llvm/llvm-project@6b539f5eb8ef1d3a3c87873caa2dbd5147e1adbd changed `isSectionBitcode` works and it now only respects `.llvm.lto` sections instead of also `.llvmbc`, which it says was never intended to be used for LTO. We instead load sections by name, and sniff for raw bitcode by hand.
This is an alternative approach to #115136, where we tried the same thing using the `object` crate, but it got too fraught to continue.
r? `@nikic`
`@rustbot` label: +llvm-main
|
|
LLVM already supports emitting compressed debuginfo. In debuginfo=full
builds, the debug section is often a large amount of data, and it
typically compresses very well (3x is not unreasonable.) We add a new
knob to allow debuginfo to be compressed when the matching LLVM
functionality is present. Like clang, if a known-but-disabled
compression mechanism is requested, we disable compression and emit
uncompressed debuginfo sections.
The API is different enough on older LLVMs we just pretend the support
is missing on LLVM older than 16.
|
