summary refs log tree commit diff
path: root/compiler/rustc_codegen_ssa/src/back
AgeCommit message (Collapse)AuthorLines
2023-09-29Auto merge of #113301 - Be-ing:stabilize_bundle_whole-archive, r=petrochenkovbors-7/+1
stabilize combining +bundle and +whole-archive link modifiers Per discussion on https://github.com/rust-lang/rust/issues/108081 combining +bundle and +whole-archive already works and can be stabilized independently of other aspects of the packed_bundled_libs feature. There is no risk of regression because this was not previously allowed. r? `@petrochenkov`
2023-09-25Pass name of object file to LLVM so it can correctly emit S_OBJNAMEFlorian Schmiderer-1/+8
2023-09-22Merge `ExternProviders` into the general `Providers` structOli Scherer-6/+4
2023-09-14treat host effect params as erased generics in codegenDeadbeef-3/+3
This fixes the changes brought to codegen tests when effect params are added to libcore, by not attempting to monomorphize functions that get the host param by being `const fn`.
2023-09-08Add missing Debuginfo to PDB debug file on windows.Florian Schmiderer-0/+7
Set Arg0 and CommandLineArgs in MCTargetoptions so LLVM outputs correct CL and CMD in LF_DEBUGINFO instead of empty/invalid values.
2023-08-21Always add LC_BUILD_VERSION for metadata object filesKeith Smiley-17/+12
As of Xcode 15 Apple's linker has become a bit more strict about the warnings it produces. One of those new warnings requires all valid Mach-O object files in an archive to have a LC_BUILD_VERSION load command: ``` ld: warning: no platform load command found in 'ARCHIVE[arm64][2106](lib.rmeta)', assuming: iOS-simulator ``` This was already being done for Mac Catalyst so this change expands this logic to include it for all Apple platforms. I filed this behavior change as FB12546320 and was told it was the new intentional behavior.
2023-08-18Fix ELF flag for RISC-V targets without explicit ABIGary Guo-1/+1
2023-08-18Add comment explanining unstable_target_featuresGary Guo-0/+1
2023-08-18Fix ABI flags in RISC-V/LoongArch ELF file generated by rustcGary Guo-17/+20
2023-08-15stabilize combining +bundle and +whole-archive link modifiersBe Wilson-7/+1
Currently, combining +bundle and +whole-archive works only with #![feature(packed_bundled_libs)] This crate feature is independent of the -Zpacked-bundled-libs command line option. This commit stabilizes the #![feature(packed_bundled_libs)] crate feature and implicitly enables it only when the +bundle and +whole-archive link modifiers are combined. This allows rlib crates to use the +whole-archive link modifier with native libraries and have all symbols included in the linked library to be included in downstream staticlib crates that use the rlib as a dependency. Other cases requiring the packed_bundled_libs behavior still require the -Zpacked-bundled-libs command line option, which can be stabilized independently in the future. Per discussion on https://github.com/rust-lang/rust/issues/108081 there is no risk of regression stabilizing the crate feature in this way because the combination of +bundle,+whole-archive link modifiers was previously not allowed.
2023-08-15Rollup merge of #114711 - lqd:linker-inference, r=petrochenkovGuillaume Gomez-17/+2
Infer `Lld::No` linker hint when the linker stem is a generic compiler driver This PR basically reverts the temporary solution in https://github.com/rust-lang/rust/pull/113631 to a more long-term solution. r? ``@petrochenkov`` In [this comment](https://github.com/rust-lang/rust/pull/113631#issuecomment-1634598238), you had ideas about a long-term solution: > I wonder what a good non-temporary solution for the inference would look like. > > * If the default is `(Cc::No, Lld::Yes)` (e.g. `rust-lld`) > > * and we switch to some specific platform compiler (e.g. `-C linker=arm-none-eabi-gcc`), should we change to `Lld::No`? Maybe yes? > * and we switch to some non-default but generic compiler `-C linker=clang`? Then maybe not? > > * If the default is `(Cc::Yes, Lld::Yes)` (e.g. future x86_64 linux with default LLD) > > * and we switch to some specific platform compiler (e.g. `-C linker=arm-none-eabi-gcc`), should we change to `Lld::No`? Maybe yes? > * and we switch to some non-default but generic compiler `-C linker=clang`? Then maybe not? > I believe that we should infer the `Lld::No` linker hint for any `-Clinker` override, and all the cases above: - the linker drivers have their own defaults, so in my mind `-Clinker` is a signal to use its default linker / flavor, rather than ours or the target's. In the case of generic compilers, it's more likely than not going to be `Lld::No`. I would expect this to be the case in general, even when including platform-specific compilers. - the guess will be wrong if the linker driver uses lld by default (and we also don't want to search for `-fuse-ld` link args), but will work in the more common cases. And the minority of other cases can fix the wrong guess by opting into the precise linker flavor. - this also ensures backwards-compatibility: today, even on targets with an lld default and overriding the linker, rustc will not use lld. That includes `thumbv6m-none-eabi` where issue #113597 happened. It looks like the simplest option, and the one with least churn: we maintain the current behavior in ambiguous cases. I've tested that this works on #113597, as expected from the failure. (I also have a no-std `run-make` test using a custom target json spec: basically simulating a future `x86_64-unknown-linux-gnu` using an lld flavor by default, to check that e.g. `-Clinker=clang` doesn't use lld. I could add that test to this PR, but IIUC such a custom target requires `cargo -Z build-std` and we have no tests depending on this cargo feature yet. Let me know if you want to add this test of the linker inference for such targets.) What do you think ?
2023-08-14add `rustc_codegen_ssa` support for csky and correct some codeDirreke-0/+8
2023-08-10Revert "make MCP510 behavior explicitly opt-in"Rémy Rakic-17/+2
This reverts commit 2b61a5e17a6bcb552889966f8f932aa680826ab6.
2023-08-09rustc: Move `stable_crate_id` from `Session` to `GlobalCtxt`Vadim Petrochenkov-1/+1
Removes a piece of mutable state. Follow up to #114578.
2023-08-09rustc: Move `crate_types` from `Session` to `GlobalCtxt`Vadim Petrochenkov-13/+15
Removes a piece of mutable state. Follow up to #114578.
2023-08-09Auto merge of #114470 - ↵bors-3/+22
pnkfelix:dont-export-no-mangle-from-proc-macros-issue-99978, r=bjorn3 Restrict linker version script of proc-macro crates to just its two symbols Restrict linker version script of proc-macro crates to just the two symbols of each proc-macro crate. The main known effect of doing this is to stop including `#[no_mangle]` symbols in the linker version script. Background: The combination of a proc-macro crate with an import of another crate that itself exports a no_mangle function was broken for a period of time, because: * In PR #99944 we stopped exporting no_mangle symbols from proc-macro crates; proc-macro crates have a very limited interface and are meant to be treated as a blackbox to everything except rustc itself. However: he constructed linker version script still referred to them, but resolving that discrepancy was left as a FIXME in the code, tagged with issue #99978. * In PR #108017 we started telling the linker to check (via the`--no-undefined-version` linker invocation flag) that every symbol referenced in the "linker version script" is provided as linker input. So the unresolved discrepancy from #99978 started surfacing as a compile-time error (e.g. #111888). Fix #111888 Fix #99978.
2023-08-08Rollup merge of #114376 - ↵Matthias Krüger-9/+0
inferiorhumanorgans:rustc-codegen-ssa-duplicate-export, r=wesleywiser Avoid exporting __rust_alloc_error_handler_should_panic more than once. Exporting `__rust_alloc_error_handler_should_panic` multiple times causes `ld.gold` to balk with: `error: version script assignment of to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined` Specifically this breaks builds of 1.70.0 and newer on DragonFly and YoctoProject with `ld.gold`. Builds with `ld.bfd` and `lld` should be unaffected. http://errors.yoctoproject.org/Errors/Details/708194/
2023-08-07Review feedback: return empty iff !should_codegen, and use simpler ↵Felix S. Klock II-12/+5
unconditional logic otherwise.
2023-08-04special-case proc-macro crates in ↵Felix S. Klock II-3/+29
rustc_codegen_ssa::back::linker::exported_symbols to only export the two symbols that proc-macros need.
2023-08-03Handle non-utf8 rpaths (fix FIXME)Martin Nordholts-32/+39
2023-08-02Avoid exporting symbols more than once.Alex Zepeda-9/+0
Exporting `__rust_alloc_error_handler_should_panic` multiple times causes ld.gold to balk with: `error: version script assignment of to symbol __rust_alloc_error_handler_should_panic failed: symbol not defined` Specifically this breaks builds on DragonFly and YoctoProject with ld.gold. Builds with ld.bfd should be unaffected.
2023-07-31Rollup merge of #113717 - cuishuang:master, r=NilstriebMatthias Krüger-1/+1
remove repetitive words
2023-07-31remove repetitive wordscui fliter-1/+1
Signed-off-by: cui fliter <imcusg@gmail.com>
2023-07-31Clean up `generate_lto_work`.Nicholas Nethercote-22/+23
This function has some shared code for the thin LTO and fat LTO cases, but those cases have so little in common that it's actually clearer to treat them fully separately.
2023-07-31Fix LLVM thread names on Windows.Nicholas Nethercote-3/+3
PR #112946 tweaked the naming of LLVM threads, but messed things up slightly, resulting in threads on Windows having names like `optimize module {} regex.f10ba03eb5ec7975-cgu.0`. This commit removes the extraneous `{} `.
2023-07-31Introduce `running_with_any_token` closure.Nicholas Nethercote-7/+10
It makes things a little clearer.
2023-07-31Use standard Rust capitalization rules for names containing "LTO".Nicholas Nethercote-9/+9
2023-07-31Tweak structure of the message loop.Nicholas Nethercote-17/+20
The main loop has a *very* complex condition, which includes two mentions of `codegen_state`. The body of the loop then immediately switches on the `codegen_state`. I find it easier to understand if it's a `loop` and we check for exit conditions after switching on `codegen_state`. We end up with a tiny bit of code duplication, but it's clear that (a) we never exit in the `Ongoing` case, (b) we exit in the `Completed` state only if several things are true (and there's interaction with LTO there), and (c) we exit in the `Aborted` state if a couple of things are true. Also, the exit conditions are all simple conjunctions.
2023-07-31Tweak a loop condition.Nicholas Nethercote-7/+11
This loop condition involves `codegen_state`, `work_items`, and `running_with_own_token`. But the body of the loop cannot modify `codegen_state`, so repeatedly checking it is unnecessary.
2023-07-31Move `maybe_start_llvm_timer`'s body into `spawn_work`.Nicholas Nethercote-26/+18
The two functions are alway called together. This commit factors out the repeated code.
2023-07-31Remove `CodegenContext::worker`.Nicholas Nethercote-24/+12
`CodegenContext` is immutable except for the `worker` field - we clone `CodegenContext` in multiple places, changing the `worker` field each time. It's simpler to move the `worker` field out of `CodegenContext`.
2023-07-31Give the coordinator thread a name.Nicholas Nethercote-3/+4
This is useful when profiling with a profiler like Samply.
2023-07-31Remove an unnecessary `pub`.Nicholas Nethercote-1/+1
2023-07-31Rename `MainThreadWorkerState`.Nicholas Nethercote-25/+25
The `Worker` is unnecessary, and just makes it longer than necessary.
2023-07-31Rename things related to the main thread's operations.Nicholas Nethercote-30/+46
It took me some time to understand how the main thread can lend a jobserver token to an LLVM thread. This commit renames a couple of things to make it clearer. - Rename the `LLVMing` variant as `Lending`, because that is a clearer description of what is happening. - Rename `running` as `running_with_own_token`, which makes it clearer that there might be one additional LLVM thread running (with a loaned token). Also add a comment to its definition.
2023-07-31Add some assertions.Nicholas Nethercote-0/+4
- Thin and fat LTO can't happen together. - `NeedsLink` and (non-allocator) `Compiled` work item results can't happen together.
2023-07-31Add comments to `WorkItemResult`.Nicholas Nethercote-4/+14
And rename the `Compiled` variant as `Finished`, because that name makes it clearer there is nothing left to do, contrasting nicely with the `Needs*` variants.
2023-07-31Inline and remove `submit_pre_codegened_module_to_llvm`.Nicholas Nethercote-13/+0
It has a single callsite, and provides little value.
2023-07-30inline format!() args up to and including rustc_codegen_llvmMatthias Krüger-45/+43
2023-07-25Use a builder instead of boolean/option argumentsOli Scherer-1/+1
2023-07-21Rollup merge of #113780 - dtolnay:printkindpath, r=b-naberMatthias Krüger-11/+28
Support `--print KIND=PATH` command line syntax As is already done for `--emit KIND=PATH` and `-L KIND=PATH`. In the discussion of #110785, it was pointed out that `--print KIND=PATH` is nicer than trying to apply the single global `-o` path to `--print`'s output, because in general there can be multiple print requests within a single rustc invocation, and anyway `-o` would already be used for a different meaning in the case of `link-args` and `native-static-libs`. I am interested in using `--print cfg=PATH` in Buck2. Currently Buck2 works around the lack of support for `--print KIND=PATH` by [indirecting through a Python wrapper script](https://github.com/facebook/buck2/blob/d43cf3a51a31f00be2c2248e78271b0fef0452b4/prelude/rust/tools/get_rustc_cfg.py) to redirect rustc's stdout into the location dictated by the build system. From skimming Cargo's usages of `--print`, it definitely seems like it would benefit from `--print KIND=PATH` too. Currently it is working around the lack of this by inserting `--crate-name=___ --print=crate-name` so that it can look for a line containing `___` as a delimiter between the 2 other `--print` informations it actually cares about. This is commented as a "HACK" and "abuse". https://github.com/rust-lang/cargo/blob/31eda6f7c360d9911f853b3014e057db61238f3e/src/cargo/core/compiler/build_context/target_info.rs#L242 (FYI `@weihanglo` as you dealt with this recently in https://github.com/rust-lang/cargo/pull/11633.) Mentioning reviewers active in #110785: `@fee1-dead` `@jyn514` `@bjorn3`
2023-07-21Rollup merge of #113723 - khei4:khei4/llvm-stats, r=oli-obk,nikicMatthias Krüger-0/+4
Resurrect: rustc_llvm: Add a -Z `print-codegen-stats` option to expose LLVM statistics. This resurrects PR https://github.com/rust-lang/rust/pull/104000, which has sat idle for a while. And I want to see the effect of stack-move optimizations on LLVM (like https://reviews.llvm.org/D153453) :). I have applied the changes requested by `@oli-obk` and `@nagisa` https://github.com/rust-lang/rust/pull/104000#discussion_r1014625377 and https://github.com/rust-lang/rust/pull/104000#discussion_r1014642482 in the latest commits. r? `@oli-obk` ----- LLVM has a neat [statistics](https://llvm.org/docs/ProgrammersManual.html#the-statistic-class-stats-option) feature that tracks how often optimizations kick in. It's very handy for optimization work. Since we expose the LLVM pass timings, I thought it made sense to expose the LLVM statistics too. ----- (Edit: fix broken link (Edit2: fix segmentation fault and use malloc If `rustc` is built with ```toml [llvm] assertions = true ``` Then you can see like ``` rustc +stage1 -Z print-codegen-stats -C opt-level=3 tmp.rs ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== 3 aa - Number of MayAlias results 193 aa - Number of MustAlias results 531 aa - Number of NoAlias results ... ``` And the current default build emits only ``` $ rustc +stage1 -Z print-codegen-stats -C opt-level=3 tmp.rs ===-------------------------------------------------------------------------=== ... Statistics Collected ... ===-------------------------------------------------------------------------=== $ ``` This might be better to emit the message to tell assertion flag necessity, but now I can't find how to do that...
2023-07-20Add note about writing native-static-libs to fileDavid Tolnay-1/+6
2023-07-20Implement printing to file for link-args and native-static-libsDavid Tolnay-10/+22
2023-07-20Store individual output file name with every PrintRequestDavid Tolnay-3/+3
2023-07-20Auto merge of #113695 - bjorn3:fix_rlib_cdylib_metadata_handling, ↵bors-13/+7
r=pnkfelix,petrochenkov Verify that all crate sources are in sync This ensures that rustc will not attempt to link against a cdylib as if it is a rust dylib when an rlib for the same crate is available. Previously rustc didn't actually check if any further formats of a crate which has been loaded are of the same version and if they are actually valid. This caused a cdylib to be interpreted as rust dylib as soon as the corresponding rlib was loaded. As cdylibs don't export any rust symbols, linking would fail if rustc decides to link against the cdylib rather than the rlib. Two crates depended on the previous behavior by separately compiling a test crate as both rlib and dylib. These have been changed to capture their original spirit to the best of my ability while still working when rustc verifies that all crates are in sync. It is unlikely that build systems depend on the current behavior and in any case we are taking a lot of measures to ensure that any change to either the source or the compilation options (including crate type) results in rustc rejecting it as incompatible. We merely didn't do this check here for now obsolete perf reasons. Fixes https://github.com/rust-lang/rust/issues/10786 Fixes https://github.com/rust-lang/rust/issues/82151 Fixes https://github.com/rust-lang/rust/issues/82972 Closes https://github.com/bevy-cheatbook/bevy-cheatbook/issues/114
2023-07-19Fix review commentsbjorn3-7/+7
2023-07-19Don't compress dylib metadatabjorn3-8/+2
2023-07-19On nightly, dump ICE backtraces to diskEsteban Küber-1/+1
Implement rust-lang/compiler-team#578. When an ICE is encountered on nightly releases, the new rustc panic handler will also write the contents of the backtrace to disk. If any `delay_span_bug`s are encountered, their backtrace is also added to the file. The platform and rustc version will also be collected.
2023-07-18support for mips32r6 as a target_arch valuechenx97-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-03 11:08:05 +0000