https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try-perf 2023-01-11T09:32:08+00:00 2023-01-11T09:32:08+00:00 Albert Larsan 74931857+albertlarsan68@users.noreply.github.com 2023-01-05T08:13:28+00:00 urn:sha1:cf2dff2b1e3fa55fa5415d524200070d0d7aacfe 2022-12-25T18:48:48+00:00 Camille GILLOT gillot.camille@gmail.com 2022-10-31T16:43:37+00:00 urn:sha1:5b9360bb1e0ca80831ef80d521aaf0815ea6e303 2022-08-31T10:24:55+00:00 Dezhi Wu wu543065657@163.com 2022-08-18T02:13:37+00:00 urn:sha1:b1430fb7ca499d517d9f4b3b6c5a81442129c88b This PR will fix some typos detected by [typos]. I only picked the ones I was sure were spelling errors to fix, mostly in the comments. [typos]: https://github.com/crate-ci/typos 2021-09-10T18:19:38+00:00 Camille GILLOT gillot.camille@gmail.com 2021-04-22T19:33:16+00:00 urn:sha1:11a999e63493c179bbefb3ce8dde4c698a4b690c 2021-08-22T13:35:11+00:00 Frank Steffahn frank.steffahn@stu.uni-kiel.de 2021-08-22T12:46:15+00:00 urn:sha1:bf88b113eab9c36e63f8461f5849138cb60d810a 2020-09-18T02:04:13+00:00 Aaron Hill aa1ronham@gmail.com 2020-09-17T21:36:13+00:00 urn:sha1:cfe07cd42a92610219d6ffc1ae5eefef42f5254a During incremental ThinLTO compilation, we attempt to re-use the optimized (post-ThinLTO) bitcode file for a module if it is 'safe' to do so. Up until now, 'safe' has meant that the set of modules that our current modules imports from/exports to is unchanged from the previous compilation session. See PR #67020 and PR #71131 for more details. However, this turns out be insufficient to guarantee that it's safe to reuse the post-LTO module (i.e. that optimizing the pre-LTO module would produce the same result). When LLVM optimizes a module during ThinLTO, it may look at other information from the 'module index', such as whether a (non-imported!) global variable is used. If this information changes between compilation runs, we may end up re-using an optimized module that (for example) had dead-code elimination run on a function that is now used by another module. Fortunately, LLVM implements its own ThinLTO module cache, which is used when ThinLTO is performed by a linker plugin (e.g. when clang is used to compile a C proect). Using this cache directly would require extensive refactoring of our code - but fortunately for us, LLVM provides a function that does exactly what we need. The function `llvm::computeLTOCacheKey` is used to compute a SHA-1 hash from all data that might influence the result of ThinLTO on a module. In addition to the module imports/exports that we manually track, it also hashes information about global variables (e.g. their liveness) which might be used during optimization. By using this function, we shouldn't have to worry about new LLVM passes breaking our module re-use behavior. In LLVM, the output of this function forms part of the filename used to store the post-ThinLTO module. To keep our current filename structure intact, this PR just writes out the mapping 'CGU name -> Hash' to a file. To determine if a post-LTO module should be reused, we compare hashes from the previous session. This should unblock PR #75199 - by sheer chance, it seems to have hit this issue due to the particular CGU partitioning and optimization decisions that end up getting made. 2020-04-14T14:52:19+00:00 Felix S. Klock II pnkfelix@pnkfx.org 2020-04-14T14:52:19+00:00 urn:sha1:12207f6c66f6fa5a19790c9c8bf1b398a7dc263d Namely, a regression test for issue #69798 (export added), and the inverse of that test (export removd). 2020-03-06T14:19:31+00:00 Matthias Krüger matthias.krueger@famsik.de 2020-03-06T11:13:55+00:00 urn:sha1:136ad015b6862274bf8c161dc5d2955409ed1465 2019-12-20T03:47:28+00:00 Felix S. Klock II pnkfelix@pnkfx.org 2019-12-06T14:57:52+00:00 urn:sha1:42b00a46812bd6af74880984d66a5eac59fca43b 2019-07-02T21:30:28+00:00 Yuki Okushi huyuumi.dev@gmail.com 2019-07-02T21:30:28+00:00 urn:sha1:c004451a209dce4960fc295ff799e17f2630a00c