https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.72.0 2023-07-02T12:48:44+00:00 2023-07-02T12:48:44+00:00 bors bors@rust-lang.org 2023-07-02T12:48:44+00:00 urn:sha1:131a03664ef90d6443dfb567ac19e5466baa937f 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-02T11:41:36+00:00 Jakub Beránek berykubik@gmail.com 2023-06-25T21:39:02+00:00 urn:sha1:62728c7aaff0441b12057de8f1be620feb96652c 2023-06-25T23:14:45+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-21T22:58:48+00:00 urn:sha1:666b1b68a7200513872303f1bc8136088a09d4ad For non-incremental builds on Unix, currently all the thread names look like `opt regex.f10ba03eb5ec7975-cgu.0`. But they are truncated by `pthread_setname` to `opt regex.f10ba`, hiding the numeric suffix that distinguishes them. This is really annoying when using a profiler like Samply. This commit changes these thread names to a form like `opt cgu.0`, which is much better. 2023-06-21T23:07:19+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-20T05:08:49+00:00 urn:sha1:fae4f452141568193c1a833b16b5589beb19334e 2023-06-21T23:07:15+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-20T04:05:55+00:00 urn:sha1:3bbf9f0128517815946a0c20efd7d80142dc050d The codegen main loop has two bools, `codegen_done` and `codegen_aborted`. There are only three valid combinations: `(false, false)`, `(true, false)`, `(true, true)`. This commit replaces them with a single tri-state enum, which makes things clearer. 2023-06-21T22:07:59+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-20T02:57:38+00:00 urn:sha1:a521ba400dbfb2e9907238a4e7a5650d22bf2068 This is particularly useful for `Message`. 2023-06-21T22:07:59+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-20T02:43:29+00:00 urn:sha1:88cd8f93247a09fb0c2e43e82e0dfedea23e9642 `Message` is an enum with multiple variants. Four of those variants map directly onto the four variants of `WorkItemResult`. This commit reduces those four `Message` variants to a single variant containing a `WorkItemResult`. This requires increasing `WorkItemResult`'s visibility to `pub(crate)` visibility, but `WorkItem` and `Message` can also have their visibility reduced to `pub(crate)`. This change avoids some boilerplate enum translation code, and makes `Message` easier to understand. 2023-06-21T22:07:59+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-20T01:45:47+00:00 urn:sha1:757c290fba5278989a78c636a41db97204693b3e `Message` is an enum with multiple variants, for messages sent to the coordinator thread. *Except* for `Message::CodegenItem`, which is entirely disjoint, being for messages sent from the coordinator thread to the main thread. This commit move `Message::CodegenItem` into a separate type, `CguMessage`, which makes the code much clearer. 2023-06-21T00:56:19+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-20T07:01:51+00:00 urn:sha1:c696307a87cffb6eafee9469858450f116b26988 They both match on a `WorkItem`. It's simpler to do it all in one place. 2023-06-14T00:57:44+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-09T04:39:13+00:00 urn:sha1:7c3ce02a1124b008addb9764173ad441f4741c00 Because tiny CGUs make compilation less efficient *and* result in worse generated code. We don't do this when the number of CGUs is explicitly given, because there are times when the requested number is very important, as described in some comments within the commit. So the commit also introduces a `CodegenUnits` type that distinguishes between default values and user-specified values. This change has a roughly neutral effect on walltimes across the rustc-perf benchmarks; there are some speedups and some slowdowns. But it has significant wins for most other metrics on numerous benchmarks, including instruction counts, cycles, binary size, and max-rss. It also reduces parallelism, which is good for reducing jobserver competition when multiple rustc processes are running at the same time. It's smaller benchmarks that benefit the most; larger benchmarks already have CGUs that are all larger than the minimum size. Here are some example before/after CGU sizes for opt builds. - html5ever - CGUs: 16, mean size: 1196.1, sizes: [3908, 2992, 1706, 1652, 1572, 1136, 1045, 948, 946, 938, 579, 471, 443, 327, 286, 189] - CGUs: 4, mean size: 4396.0, sizes: [6706, 3908, 3490, 3480] - libc - CGUs: 12, mean size: 35.3, sizes: [163, 93, 58, 53, 37, 8, 2 (x6)] - CGUs: 1, mean size: 424.0, sizes: [424] - tt-muncher - CGUs: 5, mean size: 1819.4, sizes: [8508, 350, 198, 34, 7] - CGUs: 1, mean size: 9075.0, sizes: [9075] Note that CGUs of size 100,000+ aren't unusual in larger programs.