rust/compiler/rustc_llvm/llvm-wrapper/RustWrapper.cpp, branch 1.74.0

debuginfo: add compiler option to allow compressed debuginfo sections

2023-09-08T14:45:29+00:00

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.

Rollup merge of #113593 - rcvalle:rust-cfi-fix-90546, r=wesleywiser

2023-08-08T19:44:43+00:00

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.

Only enable hotness information when PGO is available

2023-08-08T13:36:55+00:00

CFI: Fix error compiling core with LLVM CFI enabled

2023-08-07T22:59:15+00:00

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.

Add hotness data to LLVM remarks

2023-08-04T08:31:00+00:00

This makes sure that if PGO is used, remarks generated using `-Zremark-dir` will include the `Hotness` attribute.

Auto merge of #113339 - lqd:respect-filters, r=tmiasko

2023-08-01T23:15:20+00:00

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.

filter LLVM diagnostics before crossing the rust bridge

2023-08-01T21:01:20+00:00

this will eliminate many short-lived allocations (e.g. 20% of the memory used building cargo) when unpacking the diagnostic and converting its various C++ strings into rust strings, just to be filtered out most of the time.

Update the minimum external LLVM to 15

2023-07-27T21:07:08+00:00

address feedback from nikic and oli-obk https://github.com/rust-lang/rust/pull/113723/files

2023-07-20T07:53:06+00:00

use slice memcpy rather than strcpy and write it on stdout use println on failure Co-authored-by: Oli Scherer

print on rustc_codegen_llvm and rename malloc and cpy c_char

2023-07-16T15:37:52+00:00