https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.74.0 2023-09-25T17:31:58+00:00 2023-09-25T17:31:58+00:00 Florian Schmiderer florian.schmiderer@posteo.net 2023-09-09T12:00:24+00:00 urn:sha1:91544e6a937b4c2c7181578533e6d10991559c14 2023-09-24T19:11:37+00:00 Florian Schmiderer florian.schmiderer@posteo.net 2023-09-17T12:40:22+00:00 urn:sha1:3409ca65d835b858d9cefbe8949552f0f5ad0788 instead of &'static mut and provides safe interface to create/dispose it. 2023-09-08T14:45:29+00:00 Augie Fackler augie@google.com 2023-07-12T21:07:34+00:00 urn:sha1:af9e55068c2e38b1f7afc7f7374a5a53c59b2001 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-08T14:45:22+00:00 Augie Fackler augie@google.com 2023-09-07T13:48:50+00:00 urn:sha1:942bdf910cc85e6389546e25cfb391062095cbd8 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-07T22:28:40+00:00 Florian Schmiderer florian.schmiderer@posteo.net 2023-07-03T11:11:27+00:00 urn:sha1:4cdc633301e3c760fb36470afc216a9e09351fa3 Set Arg0 and CommandLineArgs in MCTargetoptions so LLVM outputs correct CL and CMD in LF_DEBUGINFO instead of empty/invalid values. 2023-08-08T19:44:43+00:00 Matthias Krüger matthias.krueger@famsik.de 2023-08-08T19:44:43+00:00 urn:sha1:c097e48082e3453bf7670c79bb1b282a9e900e1d 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-08T13:36:55+00:00 Jakub Beránek berykubik@gmail.com 2023-08-07T15:56:57+00:00 urn:sha1:9d417d7c86259498855fc50ba0e853edbb13320d 2023-08-07T22:59:15+00:00 Ramon de C Valle rcvalle@users.noreply.github.com 2023-07-11T23:19:42+00:00 urn:sha1:f837c48f0d8da1a205b7ab97846bc90f8d497271 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-01T23:15:20+00:00 bors bors@rust-lang.org 2023-08-01T23:15:20+00:00 urn:sha1:f77c624c03065298ac76051a4c1c5c2cfeafc0e0 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-01T21:01:20+00:00 Rémy Rakic remy.rakic+github@gmail.com 2023-07-14T16:09:04+00:00 urn:sha1:ca5a383fb6b16679b31029ab5da8438b5ef03e1e 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.