https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.72.0 2023-07-06T08:10:42+00:00 2023-07-06T08:10:42+00:00 bors bors@rust-lang.org 2023-07-06T08:10:42+00:00 urn:sha1:4dd1719b3406d80f539d2f49e9842f3563908632 Move `TyCtxt::mk_x` to `Ty::new_x` where applicable Part of rust-lang/compiler-team#616 turns out there's a lot of places we construct `Ty` this is a ridiculously huge PR :S r? `@oli-obk` 2023-07-05T19:27:07+00:00 Boxy supbscripter@gmail.com 2023-07-05T19:13:26+00:00 urn:sha1:12138b8e5e840b7446a0893e3cb02a9c05095930 2023-07-05T11:11:27+00:00 León Orell Valerian Liehr me@fmease.dev 2023-07-04T17:53:44+00:00 urn:sha1:3788b7ab32a6398e7563557f7b32f741f43704a3 This reverts commit a17561ffc90c900cb7d0e96b00c6381244764ef7. 2023-06-29T01:46:25+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-28T03:56:53+00:00 urn:sha1:d20b1a8f6ba8ea753726fd70ce0e525f3bccffb9 Other callsites already do this, but these two were missed. This avoids some allocations. 2023-06-29T01:31:43+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-27T22:57:32+00:00 urn:sha1:b4c6e19adeffad05e6039c21fdbda2097f3a2485 `lookup_debug_loc` finds a file, line, and column, which requires two binary searches. But this call site only needs the file. This commit replaces the call with `lookup_source_file`, which does a single binary search. 2023-06-29T01:26:39+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-06-27T22:14:29+00:00 urn:sha1:a13be655a511c215cc4d1d120d981bfe80b04eec `lookup_debug_loc` calls `SourceMap::lookup_line`, which does a binary search over the files, and then a binary search over the lines within the found file. It then calls `SourceFile::line_begin_pos`, which redoes the binary search over the lines within the found file. This commit removes the second binary search over the lines, instead getting the line starting pos directly using the result of the first binary search over the lines. (And likewise for `get_span_loc`, in the cranelift backend.) 2023-06-19T16:50:52+00:00 Camille GILLOT gillot.camille@gmail.com 2023-06-18T08:19:16+00:00 urn:sha1:3a1edd8212381d0b825a5bcb876a8f05ff3ff35a 2023-06-19T16:50:52+00:00 Camille GILLOT gillot.camille@gmail.com 2023-06-18T07:55:04+00:00 urn:sha1:7d5b2e4926385bb247c4e1f2480258ca3faf4f10 2023-06-16T19:53:22+00:00 Michael Goulet michael@errs.io 2023-06-16T19:53:22+00:00 urn:sha1:3eb8c2ae10cb47a99e7f9baed9158cedc783536f Support 128-bit enum variant in debuginfo codegen fixes #111600 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.