about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src/back
AgeCommit message (Collapse)AuthorLines
2022-12-14Auto merge of #105221 - alex:fat-archive-cleanup, r=bjorn3bors-10/+4
Avoid a temporary file when processing macOS fat archives r? `@bjorn3`
2022-12-13Rollup merge of #105620 - TaKO8Ki:remove-unnecessary-uses-of-clone, ↵Matthias Krüger-1/+1
r=compiler-errors Remove unnecessary uses of `clone`
2022-12-13remove unnecessary uses of `clone`Takayuki Maeda-1/+1
2022-12-07Don't internalize __llvm_profile_counter_biasAlex Brachet-0/+4
Currently, LLVM profiling runtime counter relocation cannot be used by rust during LTO because symbols are being internalized before all symbol information is known. This mode makes LLVM emit a __llvm_profile_counter_bias symbol which is referenced by the profiling initialization, which itself is pulled in by the rust driver here [1]. It is enabled with -Cllvm-args=-runtime-counter-relocation for platforms which are opt-in to this mode like Linux. On these platforms there will be no link error, rather just surprising behavior for a user which request runtime counter relocation. The profiling runtime will not see that symbol go on as if it were never there. On Fuchsia, the profiling runtime must have this symbol which will cause a hard link error. As an aside, I don't have enough context as to why rust's LTO model is how it is. AFAICT, the internalize pass is only safe to run at link time when all symbol information is actually known, this being an example as to why. I think special casing this symbol as a known one that LLVM can emit which should not have it's visbility de-escalated should be fine given how seldom this pattern of defining an undefined symbol to get initilization code pulled in is. From a quick grep, __llvm_profile_runtime is the only symbol that rustc does this for. [1] https://github.com/rust-lang/rust/blob/0265a3e93bf1b89d97cae113ed214954d5c35e22/compiler/rustc_codegen_ssa/src/back/linker.rs#L598
2022-12-03Remove macOS fat archive support from LlvmArchiveBuilderAlex Gaynor-10/+4
its only ever used for wasm targets
2022-11-26Use LLVM for getting symbols from COFF bigobj filesbjorn3-1/+9
2022-11-26Rewrite LLVM's archive writer in Rustbjorn3-62/+61
This allows it to be used by other codegen backends
2022-11-13Rollup merge of #104105 - davidtwco:split-dwarf-lto, r=michaelwoeristerManish Goregaokar-3/+13
llvm: dwo only emitted when object code emitted Fixes #103932. `CompiledModule` should not think a DWARF object was emitted when a bitcode-only compilation has happened, this can confuse archive file creation (which expects to create an archive containing non-existent dwo files). r? ``````@michaelwoerister``````
2022-11-09Update compiler/rustc_codegen_llvm/src/back/archive.rsSLASHLogin-1/+1
Co-authored-by: David Wood <agile.lion3441@fuligin.ink>
2022-11-09Port diagnostics created by `Handler`SLASHLogin-7/+2
2022-11-09Port `UnknownArchiveKind`SLASHLogin-4/+5
2022-11-09Port `DlltoolFailImportLibrary` and implement `IntoDiagnosticArg` for ↵SLASHLogin-6/+8
`Cow<'a, str>`
2022-11-09Port ErrorCallingDllToolSLASHLogin-2/+4
2022-11-09Import ErrorWritingDEFFileSLASHLogin-2/+2
2022-11-09Port ArchiveBuildFailureSLASHLogin-2/+2
2022-11-09Import `error creating import library`SLASHLogin-4/+4
2022-11-08llvm: dwo only emitted when object code emittedDavid Wood-3/+13
`CompiledModule` should not think a DWARF object was emitted when a bitcode-only compilation has happened, this can confuse archive file creation (which expects to create an archive containing non-existent dwo files). Signed-off-by: David Wood <david.wood@huawei.com>
2022-10-24Support raw-dylib functions being used inside inlined functionsDaniel Paoliello-2/+5
2022-10-23Introduce dedicated `-Zdylib-lto` flag for enabling LTO on `dylib`sJakub Beránek-1/+15
2022-10-23Allow LTO for dylibsbjorn3-13/+4
2022-10-14fix a typowtj-1/+1
2022-10-06Rollup merge of #102725 - nnethercote:rm-Z-time, r=davidtwcoMatthias Krüger-1/+1
Remove `-Ztime` Because it has a lot of overlap with `-Ztime-passes` but is generally less useful. Plus some related cleanups. Best reviewed one commit at a time. r? `@davidtwco`
2022-10-06Remove `-Ztime` option.Nicholas Nethercote-1/+1
The compiler currently has `-Ztime` and `-Ztime-passes`. I've used `-Ztime-passes` for years but only recently learned about `-Ztime`. What's the difference? Let's look at the `-Zhelp` output: ``` -Z time=val -- measure time of rustc processes (default: no) -Z time-passes=val -- measure time of each rustc pass (default: no) ``` The `-Ztime-passes` description is clear, but the `-Ztime` one is less so. Sounds like it measures the time for the entire process? No. The real difference is that `-Ztime-passes` prints out info about passes, and `-Ztime` does the same, but only for a subset of those passes. More specifically, there is a distinction in the profiling code between a "verbose generic activity" and an "extra verbose generic activity". `-Ztime-passes` prints both kinds, while `-Ztime` only prints the first one. (It took me a close reading of the source code to determine this difference.) In practice this distinction has low value. Perhaps in the past the "extra verbose" output was more voluminous, but now that we only print stats for a pass if it exceeds 5ms or alters the RSS, `-Ztime-passes` is less spammy. Also, a lot of the "extra verbose" cases are for individual lint passes, and you need to also use `-Zno-interleave-lints` to see those anyway. Therefore, this commit removes `-Ztime` and the associated machinery. One thing to note is that the existing "extra verbose" activities all have an extra string argument, so the commit adds the ability to accept an extra argument to the "verbose" activities.
2022-10-04resolve error when attempting to link a universal library on macOSAlex Gaynor-3/+64
Previously attempting to link universal libraries into libraries (but not binaries) would produce an error that "File too small to be an archive". This works around this by using `object` to extract a library for the target platform when passed a univeral library. Fixes #55235
2022-09-19Rename LLVM `optimize` functionsJosh Stone-4/+4
2022-09-18Remove -Znew-llvm-pass-managerJosh Stone-4/+0
2022-09-18Remove support for LLVM's legacy pass managerJosh Stone-309/+18
2022-09-01Always import all tracing macros for the entire crate instead of piecemeal ↵Oli Scherer-6/+4
by module
2022-08-30Auto merge of #98100 - bjorn3:use_object_for_bitcode_reading, r=wesleywiserbors-5/+16
Use object instead of LLVM for reading bitcode from rlibs Together with changes I plan to make as part of https://github.com/rust-lang/rust/pull/97485 this will allow entirely removing usage of LLVM's archive reader and thus allow removing `archive_ro.rs` and `ArchiveWrapper.cpp`.
2022-08-26Implementation of import_name_typeDaniel Paoliello-24/+10
2022-08-16Rollup merge of #100460 - cuviper:drop-llvm-12, r=nagisaMatthias Krüger-14/+1
Update the minimum external LLVM to 13 With this change, we'll have stable support for LLVM 13 through 15 (pending release). For reference, the previous increase to LLVM 12 was #90175. r? `@nagisa`
2022-08-14Update the minimum external LLVM to 13Josh Stone-14/+1
2022-08-12Respond to RFC comments.ridwanabdillahi-1/+1
2022-08-11Add support for generating unique *.profraw files by default when using the ↵ridwanabdillahi-0/+10
`-C instrument-coverage` flag. Respond to PR comments.
2022-07-28Introduce an ArchiveBuilderBuilderbjorn3-12/+16
This avoids monomorphizing all linker code for each codegen backend and will allow passing in extra information to the archive builder from the codegen backend.
2022-07-28Inline inject_dll_import_libbjorn3-4/+0
2022-07-28Move output argument from ArchiveBuilder::new to .build()bjorn3-7/+6
2022-07-26Auto merge of #98989 - dpaoliello:rawdylibbin, r=michaelwoeristerbors-24/+20
Enable raw-dylib for bin crates Fixes #93842 When `raw-dylib` is used in a `bin` crate, we need to collect all of the `raw-dylib` functions, generate the import library and add that to the linker command line. I also changed the tests so that 1) the C++ dlls are created after the Rust dlls, thus there is no chance of accidentally using them in the Rust linking process and 2) disabled generating import libraries when building with MSVC.
2022-07-25Use object instead of LLVM for reading bitcode from rlibsbjorn3-5/+16
2022-07-22Enable raw-dylib for binariesDaniel Paoliello-24/+20
2022-07-21Auto merge of #98162 - nextsilicon:support_lto_embed_bitcode, r=davidtwcobors-4/+4
Allow to disable thinLTO buffer to support lto-embed-bitcode lld feature Hello This change is to fix issue (https://github.com/rust-lang/rust/issues/84395) in which passing "-lto-embed-bitcode=optimized" to lld when linking rust code via linker-plugin-lto doesn't produce the expected result. Instead of emitting a single unified module into a llvmbc section of the linked elf, it emits multiple submodules. This is caused because rustc emits the BC modules after running llvm `createWriteThinLTOBitcodePass` pass. Which in turn triggers a thinLTO linkage and causes the said issue. This patch allows via compiler flag (-Cemit-thin-lto=<bool>) to select between running `createWriteThinLTOBitcodePass` and `createBitcodeWriterPass`. Note this pattern of selecting between those 2 passes is common inside of LLVM code. The default is to match the old behavior.
2022-07-16Auto merge of #95685 - oxidecomputer:restore-static-dwarf, r=pnkfelixbors-16/+2
Revert "Work around invalid DWARF bugs for fat LTO" Since September, the toolchain has not been generating reliable DWARF information for static variables when LTO is on. This has affected projects in the embedded space where the use of LTO is typical. In our case, it has kept us from bumping past the 2021-09-22 nightly toolchain lest our debugger break. This has been a pretty dramatic regression for people using debuggers and static variables. See #90357 for more info and a repro case. This commit is a mechanical revert of d5de680e20def848751cb3c11e1182408112b1d3 from PR #89041, which caused the issue. (Note on that PR that the commit's author has requested it be reverted.) I have locally verified that this fixes #90357 by restoring the functionality of both the repro case I posted on that bug, and debugger behavior on real programs. There do not appear to be test cases for this in the toolchain; if I've missed them, point me at 'em and I'll update them.
2022-07-14rustc: add ability to output regular LTO bitcode modulesZiv Dunkelman-4/+4
Adding the option to control from rustc CLI if the resulted ".o" bitcode module files are with thinLTO info or regular LTO info. Allows using "-lto-embed-bitcode=optimized" during linkage correctly. Signed-off-by: Ziv Dunkelman <ziv.dunkelman@nextsilicon.com>
2022-07-13Rename `debugging_opts` to `unstable_opts`Joshua Nelson-8/+8
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`). Rename it to be more clear.
2022-06-21Auto merge of #98098 - bjorn3:archive_refactor, r=michaelwoeristerbors-95/+25
Remove the source archive functionality of ArchiveWriter We now build archives through strictly additive means rather than taking an existing archive and potentially substracting parts. This is simpler and makes it easier to swap out the archive writer in https://github.com/rust-lang/rust/pull/97485.
2022-06-19Small refactoringbjorn3-9/+5
2022-06-19Remove the source archive functionality of ArchiveWriterbjorn3-33/+2
We now build archives through strictly additive means rather than taking an existing archive and potentially substracting parts.
2022-06-19Fix "Remove src_files and remove_file"bjorn3-5/+6
2022-06-16Rollup merge of #97757 - xFrednet:rfc-2383-expect-with-force-warn, ↵Matthias Krüger-1/+1
r=wesleywiser,flip1995 Support lint expectations for `--force-warn` lints (RFC 2383) Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope. This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust. This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix. --- r? `@wesleywiser` cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. :upside_down_face: Follow-up of: https://github.com/rust-lang/rust/pull/87835 Issue: https://github.com/rust-lang/rust/issues/85549 Yeah, and that's it.
2022-06-16Support lint expectations for `--force-warn` lints (RFC 2383)xFrednet-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 23:31:20 +0000