https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.57.0 2021-10-06T19:36:52+00:00 2021-10-06T19:36:52+00:00 Michael Benfield mbenfield@google.com 2021-05-07T07:41:37+00:00 urn:sha1:a17193dbb931ea0c8b66d82f640385bce8b4929a This largely involves implementing the options debug-info-for-profiling and profile-sample-use and forwarding them on to LLVM. AutoFDO can be used on x86-64 Linux like this: rustc -O -Cdebug-info-for-profiling main.rs -o main perf record -b ./main create_llvm_prof --binary=main --out=code.prof rustc -O -Cprofile-sample-use=code.prof main.rs -o main2 Now `main2` will have feedback directed optimization applied to it. The create_llvm_prof tool can be obtained from this github repository: https://github.com/google/autofdo Fixes #64892. 2021-09-27T22:11:21+00:00 Augie Fackler augie@google.com 2021-09-27T21:03:08+00:00 urn:sha1:12c3f50a90b96fff93399f3039155da3ef96abb0 thinLTOResolvePrevailingInModule became thinLTOFinalizeInModule and gained the ability to propagate noRecurse and noUnwind function attributes. I ran codegen tests with it both on and off, as the upstream patch uses it in both modes, and the tests pass both ways. Given that, it seemed reasonable to go ahead and let the propagation be enabled in rustc, and see what happens. See https://reviews.llvm.org/D36850 for more examples of how the new version of the function gets used. 2021-09-25T09:24:23+00:00 Nikita Popov nikita.ppv@gmail.com 2021-09-13T16:18:59+00:00 urn:sha1:074bbc6b878f6afc5d6cfd1b5cce1e03588d8184 Unlike the pre-link piplines, the LTO pipelines do support O0, and using them is required to avoid leaving behind undefined references for the linker. 2021-09-22T17:03:21+00:00 the8472 the8472@users.noreply.github.com 2021-09-22T17:03:21+00:00 urn:sha1:1deef1f75d0761256578508c1b398718e121d094 Work around invalid DWARF bugs for fat LTO This PR applies the same workaround in #46772 to fat LTO. It seems to fix the bug reported in https://github.com/rust-lang/rust/issues/66118#issuecomment-917434036. 2021-09-17T15:19:38+00:00 Yilin Chen sticnarf@gmail.com 2021-09-17T12:21:33+00:00 urn:sha1:d5de680e20def848751cb3c11e1182408112b1d3 Signed-off-by: Yilin Chen <sticnarf@gmail.com> 2021-09-17T15:07:14+00:00 John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de 2021-08-25T07:49:17+00:00 urn:sha1:fa27d50caa5b0972803b957212a813b582a6c013 2021-09-16T19:04:18+00:00 Augie Fackler augie@google.com 2021-09-16T19:04:18+00:00 urn:sha1:bc4d8af123ce376261b1abd7acbc7d67a0197280 2021-09-16T15:49:02+00:00 Augie Fackler augie@google.com 2021-09-16T15:45:38+00:00 urn:sha1:a97f89aeb4b4d7e2131f34c067df0f952fb8caad Change ab41eef9aca3 in LLVM split MemorySanitizerPass into MemorySanitizerPass for functions and ModuleMemorySanitizerPass for modules. There's a related change for ThreadSanitizerPass, and in here since we're using a ModulePassManager I only add the module flavor of the pass on LLVM 14. r? @nikic cc @nagisa 2021-08-19T16:44:54+00:00 Augie Fackler augie@google.com 2021-08-19T16:40:37+00:00 urn:sha1:c4e6185385148ec964d2765957a83bdf3df7b112 These API changes appear to have all taken place in https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and AddressSanitizerPass to only accept their options type as a ctor argument instead of the sequence of bools etc. This required a couple of parameter additions, which I made match the default prior to the mentioned upstream LLVM change. This patch restores rustc to building (though not quite passing all tests, I've mailed other patches for those issues) against LLVM HEAD. 2021-08-06T22:08:04+00:00 Augie Fackler augie@google.com 2021-08-05T16:13:58+00:00 urn:sha1:482f1901b0c9bfecc1d433670ba32fcc482b8867 This is the first build break of the LLVM 14 cycle, and was caused by https://reviews.llvm.org/D107025. Mercifully an easy fix.