about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src/back
AgeCommit message (Collapse)AuthorLines
2023-09-10Remove `verbose_generic_activity_with_arg`John Kåre Alsaker-1/+1
2023-09-08debuginfo: add compiler option to allow compressed debuginfo sectionsAugie Fackler-1/+22
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.
2023-09-08lto: handle Apple platforms correctly by eliding __LLVM, from section nameAugie Fackler-1/+4
2023-09-08lto: load bitcode sections by nameAugie Fackler-16/+47
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. r? @nikic @rustbot label: +llvm-main
2023-09-08Add missing Debuginfo to PDB debug file on windows.Florian Schmiderer-0/+20
Set Arg0 and CommandLineArgs in MCTargetoptions so LLVM outputs correct CL and CMD in LF_DEBUGINFO instead of empty/invalid values.
2023-09-01remove unnecessary heap allocationXXIV-2/+2
2023-08-08Rollup merge of #113593 - rcvalle:rust-cfi-fix-90546, r=wesleywiserMatthias Krüger-0/+3
CFI: Fix error compiling core with LLVM CFI enabled Fix #90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
2023-08-08Only enable hotness information when PGO is availableJakub Beránek-0/+2
2023-08-07CFI: Fix error compiling core with LLVM CFI enabledRamon de C Valle-0/+3
Fix #90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
2023-08-01Auto merge of #113339 - lqd:respect-filters, r=tmiaskobors-23/+16
Filter out short-lived LLVM diagnostics before they reach the rustc handler During profiling I saw remark passes being unconditionally enabled: for example `Machine Optimization Remark Emitter`. The diagnostic remarks enabled by default are [from missed optimizations and opt analyses](https://github.com/rust-lang/rust/pull/113339#discussion_r1259480303). They are created by LLVM, passed to the diagnostic handler on the C++ side, emitted to rust, where they are unpacked, C++ strings are converted to rust, etc. Then they are discarded in the vast majority of the time (i.e. unless some kind of `-Cremark` has enabled some of these passes' output to be printed). These unneeded allocations are very short-lived, basically only lasting between the LLVM pass emitting them and the rust handler where they are discarded. So it doesn't hugely impact max-rss, and is only a slight reduction in instruction count (cachegrind reports a reduction between 0.3% and 0.5%) _on linux_. It's possible that targets without `jemalloc` or with a worse allocator, may optimize these less. It is however significant in the aggregate, looking at the total number of allocated bytes: - it's the biggest source of allocations according to dhat, on the benchmarks I've tried e.g. `syn` or `cargo` - allocations on `syn` are reduced by 440MB, 17% (from 2440722647 bytes total, to 2030461328 bytes) - allocations on `cargo` are reduced by 6.6GB, 19% (from 35371886402 bytes total, to 28723987743 bytes) Some of these diagnostics objects [are allocated in LLVM](https://github.com/rust-lang/rust/pull/113339#discussion_r1252387484) *before* they're emitted to our diagnostic handler, where they'll be filtered out. So we could remove those in the future, but that will require changing a few LLVM call-sites upstream, so I left a FIXME.
2023-08-01remove remark filtering on the rust sideRémy Rakic-23/+16
now that remarks are filtered before cg_llvm's diagnostic handler callback is called, we don't need to do the filtering post c++-to-rust conversion of the diagnostic.
2023-08-01Auto merge of #105545 - erikdesjardins:ptrclean, r=bjorn3bors-4/+3
cleanup: remove pointee types This can't be merged until the oldest LLVM version we support uses opaque pointers, which will be the case after #114148. (Also note `-Cllvm-args="-opaque-pointers=0"` can technically be used in LLVM 15, though I don't think we should support that configuration.) I initially hoped this would provide some minor perf win, but in https://github.com/rust-lang/rust/pull/105412#issuecomment-1341224450 it had very little impact, so this is only valuable as a cleanup. As a followup, this will enable #96242 to be resolved. r? `@ghost` `@rustbot` label S-blocked
2023-07-31Use standard Rust capitalization rules for names containing "LTO".Nicholas Nethercote-5/+5
2023-07-30inline format!() args up to and including rustc_codegen_llvmMatthias Krüger-11/+11
2023-07-29cg_llvm: remove pointee types and pointercast/bitcast-of-ptrErik Desjardins-4/+3
2023-07-19Auto merge of #112591 - jfgoog:better-dlltool-diagnostics, r=WaffleLapkinbors-19/+24
Better diagnostics for dlltool errors. When dlltool fails, show the full command that was executed. In particular, llvm-dlltool is not very helpful, printing a generic usage message rather than what actually went wrong, so stdout and stderr aren't of much use when troubleshooting.
2023-07-17Better diagnostics for dlltool errors.James Farrell-19/+24
When dlltool fails, show the full command that was executed. In particular, llvm-dlltool is not very helpful, printing a generic usage message rather than what actually went wrong, so stdout and stderr aren't of much use when troubleshooting.
2023-07-05Revert "use new c literals instead of cstr! macro"León Orell Valerian Liehr-9/+9
This reverts commit a17561ffc90c900cb7d0e96b00c6381244764ef7.
2023-07-02Auto merge of #113040 - Kobzol:llvm-remark-streamer, r=tmiaskobors-5/+46
Add `-Zremark-dir` unstable flag to write LLVM optimization remarks to YAML This PR adds an option for `rustc` to emit LLVM optimization remarks to a set of YAML files, which can then be digested by existing tools, like https://github.com/OfekShilon/optview2. When `-Cremark-dir` is passed, and remarks are enabled (`-Cremark=all`), the remarks will be now written to the specified directory, **instead** of being printed to standard error output. The files are named based on the CGU from which they are being generated. Currently, the remarks are written using the LLVM streaming machinery, directly in the diagnostics handler. It seemed easier than going back to Rust and then form there back to C++ to use the streamer from the diagnostics handler. But there are many ways to implement this, of course, so I'm open to suggestions :) I included some comments with questions into the code. Also, I'm not sure how to test this. r? `@tmiasko`
2023-07-02Add `rustc` option to output LLVM optimization remarks to YAML filesJakub Beránek-5/+46
2023-06-08Use `c`-prefixed stringKai Luo-6/+6
2023-06-08Support embedding bitcode on AIXKai Luo-2/+19
2023-05-31use new c literals instead of cstr! macroklensy-5/+5
2023-05-08Remove the ThinLTO CU hackJosh Stone-49/+0
This reverts #46722, commit e0ab5d5feb4eb2d8af11b8dd9446c2b45fada8af. Since #111167, commit 10b69dde3fd15334ea2382d2dc9e9a261de1afaf, we are generating DWARF subprograms in a way that is meant to be more compatible with LLVM's expectations, so hopefully we don't need this workaround rewriting CUs anymore.
2023-05-06Rollup merge of #111203 - Kobzol:remark-print-kind, r=tmiaskoMatthias Krüger-0/+10
Output LLVM optimization remark kind in `-Cremark` output Since https://github.com/rust-lang/rust/pull/90833, the optimization remark kind has not been printed. Therefore it wasn't possible to easily determine from the log (in a programmatic way) which remark kind was produced. I think that the most interesting remarks are the missed ones, which can lead users to some code optimization. Maybe we could also change the format closer to the "old" one: ``` note: optimization remark for tailcallelim at /checkout/src/libcore/num/mod.rs:1:0: marked this call a tail call candidate ``` I wanted to programatically parse the remarks so that they could work e.g. with https://github.com/OfekShilon/optview2. However, now that I think about it, probably the proper solution is to tell rustc to output them to YAML and then use the YAML as input for the opt remark visualization tools. The flag for enabling this does not seem to work though (https://github.com/rust-lang/rust/issues/96705#issuecomment-1117632322). Still I think that it's good to output the remark kind anyway, it's an important piece of information. r? ```@tmiasko```
2023-05-04Output LLVM optimization remark kind in `-Cremark` outputJakub Beránek-0/+10
2023-04-18Stablize raw-dylib, link_ordinal and -CdlltoolDaniel Paoliello-4/+8
2023-04-04replace LLVMRustAppendModuleInlineAsm with LLVMAppendModuleInlineAsm, ↵klensy-2/+2
LLVMRustMetadataTypeInContext with LLVMMetadataTypeInContext
2023-03-29Auto merge of #108792 - Amanieu:ohos, r=petrochenkovbors-0/+3
Add OpenHarmony targets - `aarch64-unknown-linux-ohos` - `armv7-unknown-linux-ohos` Compiler team MCP: https://github.com/rust-lang/compiler-team/issues/568
2023-03-28Add OpenHarmony targetsAmanieu d'Antras-0/+3
- `aarch64-unknown-linux-ohos` - `armv7-unknown-linux-ohos`
2023-03-24Update ar_archive_writer to 0.1.3bjorn3-1/+1
This updates object to 0.30 and fixes a bug where the symbol table would be omitted for archives where there are object files yet none that export any symbol. This bug could lead to linker errors for crates like rustc_std_workspace_core which don't contain any code of their own but exist solely for their dependencies. This is likely the cause of the linker issues I was experiencing on Webassembly. It has been shown to cause issues on other platforms too. cc rust-lang/ar_archive_writer#5
2023-03-22Use -m option instead of looking for a cross-compiling version of dlltoolDaniel Paoliello-14/+25
2023-02-25record llvm cgu instruction statscsmoe-0/+21
2023-02-18Auto merge of #99679 - repnop:kernel-address-sanitizer, r=cuviperbors-0/+4
Add `kernel-address` sanitizer support for freestanding targets This PR adds support for KASan (kernel address sanitizer) instrumentation in freestanding targets. I included the minimal set of `x86_64-unknown-none`, `riscv64{imac, gc}-unknown-none-elf`, and `aarch64-unknown-none` but there's likely other targets it can be added to. (`linux_kernel_base.rs`?) KASan uses the address sanitizer attributes but has the `CompileKernel` parameter set to `true` in the pass creation.
2023-02-16`if $c:expr { Some($r:expr) } else { None }` =>> `$c.then(|| $r)`Maybe Waffle-10/+5
2023-02-14Add `kernel-address` sanitizer support for freestanding targetsWesley Norris-0/+4
2023-02-06Specify dlltool prefix when generating import libsRafael Rivera-0/+8
2023-01-30session: diagnostic migration lint on more fnsDavid Wood-69/+60
Apply the diagnostic migration lint to more functions on `Session`. Signed-off-by: David Wood <david.wood@huawei.com>
2023-01-27Revert back to LlvmArchiveBuilder on all platformsbjorn3-1/+3
ArArchiveBuilder doesn't support reading thin archives, causing a regression.
2023-01-27Revert "Remove macOS fat archive support from LlvmArchiveBuilder"bjorn3-4/+10
This reverts commit 047c7cc60c05e2cf182c6f578581cf2a67b1d0ff.
2023-01-17Remove double spaces after dots in commentsMaybe Waffle-4/+4
2022-12-20Remove wrapper functions for some unstable optionsNilstrieb-1/+1
They are trivial and just forward to the option. Like most other options, we can just access it directly.
2022-12-18don't restuct references just to reborrowMatthias Krüger-1/+1
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 00:33:17 +0000