rust/compiler/rustc_codegen_llvm/src/back/write.rs, branch 1.61.0

Querify `global_backend_features`

2022-02-28T23:57:25+00:00

At the very least this serves to deduplicate the diagnostics that are output about unknown target features provided via CLI.

Adopt let else in more places

2022-02-19T16:27:43+00:00

sess/cg: re-introduce split dwarf kind

2022-01-06T09:32:42+00:00

In #79570, `-Z split-dwarf-kind={none,single,split}` was replaced by `-C split-debuginfo={off,packed,unpacked}`. `-C split-debuginfo`'s packed and unpacked aren't exact parallels to single and split, respectively. On Unix, `-C split-debuginfo=packed` will put debuginfo into object files and package debuginfo into a DWARF package file (`.dwp`) and `-C split-debuginfo=unpacked` will put debuginfo into dwarf object files and won't package it. In the initial implementation of Split DWARF, split mode wrote sections which did not require relocation into a DWARF object (`.dwo`) file which was ignored by the linker and then packaged those DWARF objects into DWARF packages (`.dwp`). In single mode, sections which did not require relocation were written into object files but ignored by the linker and were not packaged. However, both split and single modes could be packaged or not, the primary difference in behaviour was where the debuginfo sections that did not require link-time relocation were written (in a DWARF object or the object file). This commit re-introduces a `-Z split-dwarf-kind` flag, which can be used to pick between split and single modes when `-C split-debuginfo` is used to enable Split DWARF (either packed or unpacked). Signed-off-by: David Wood

Auto merge of #91125 - eskarn:llvm-passes-plugin-support, r=nagisa

2021-12-30T02:53:09+00:00

Allow loading LLVM plugins with both legacy and new pass manager Opening a draft PR to get feedback and start discussion on this feature. There is already a codegen option `passes` which allow giving a list of LLVM pass names, however we currently can't use a LLVM pass plugin (as described here : https://llvm.org/docs/WritingAnLLVMPass.html), the only available passes are the LLVM built-in ones. The proposed modification would be to add another codegen option `pass-plugins`, which can be set with a list of paths to shared library files. These libraries are loaded using the LLVM function `PassPlugin::Load`, which calls the expected symbol `lvmGetPassPluginInfo`, and register the pipeline parsing and optimization callbacks. An example usage with a single plugin and 3 passes would look like this in the `.cargo/config`: ```toml rustflags = [ "-C", "pass-plugins=/tmp/libLLVMPassPlugin", "-C", "passes=pass1 pass2 pass3", ] ``` This would give the same functionality as the opt LLVM tool directly integrated in rust build system. Additionally, we can also not specify the `passes` option, and use a plugin which inserts passes in the optimization pipeline, as one could do using clang.

rustc_codegen_llvm: move should_use_new_llvm_pass_manager function to llvm_util

2021-12-20T13:49:04+00:00

Rollup merge of #91931 - LegionMammal978:less-inband-codegen_llvm, r=davidtwco

2021-12-18T13:49:40+00:00

Remove `in_band_lifetimes` from `rustc_codegen_llvm` See #91867 for more information. This one took a while. This crate has dozens of functions not associated with any type, and most of them were using in-band lifetimes for `'ll` and `'tcx`.

Rollup merge of #91566 - cbeuw:remap-dwo-name, r=davidtwco

2021-12-18T13:49:38+00:00

Apply path remapping to DW_AT_GNU_dwo_name when producing split DWARF `--remap-path-prefix` doesn't apply to paths to `.o` (in case of packed) or `.dwo` (in case of unpacked) files in `DW_AT_GNU_dwo_name`. GCC also has this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91888

Remove `in_band_lifetimes` from `rustc_codegen_llvm`

2021-12-16T19:43:32+00:00

See #91867 for more information.

Revert "Produce .dwo file for Packed as well"

2021-12-13T11:40:59+00:00

This reverts commit 32810223c6b743de889eda96b442f621c293a848.

Auto merge of #91654 - nikic:llvmbc-section-flags, r=nagisa

2021-12-13T10:35:28+00:00

Use module inline assembly to embed bitcode In LLVM 14, our current method of setting section flags to avoid embedding the `.llvmbc` section into final compilation artifacts will no longer work, see issue #90326. The upstream recommendation is to instead embed the entire bitcode using module-level inline assembly, which is what this change does. I've kept the existing code for platforms where we do not need to set section flags, but possibly we should always be using the inline asm approach (which would have to look a bit different for MachO). r? `@nagisa`