- User Since
- Sep 9 2014, 6:00 AM (482 w, 3 d)
Oct 5 2023
Latest page looks fine: https://clang.llvm.org/cxx_status.html#cxx11
May 30 2023
Sep 16 2022
Given the disagreement on your measured times with and without the patch even without the -ftime-trace flag I'm inclined to write this off to very non-gaussian sampling noise on your setup. wdyt?
Sep 15 2022
@russell.gallop can you still repro a regression with the current patch?
Sep 7 2022
Something is definitely up now. With the latest patch I see a 12% decrease in performance when using -ftime-trace! With 10 runs there is no overlap between the with and without timings. Are you able to reproduce this difference on a test file?
Sep 6 2022
Thanks again @russell.gallop, PTAL.
Sep 2 2022
Thanks for splitting this out. Generally looks good with some comments, and thanks for adding the unit test.
Sep 1 2022
This looks interesting. Does this help with the case @mehdi_amini outlined here: https://reviews.llvm.org/D118550/new/#3323665 ? It would be great to be able to get the TimeProfile to trace anything multi-threaded in LLVM (anything using Thread Pool), rather than having to hook it into each use.
Aug 22 2022
Resign as reviewer as I work with Carlos (and am not familiar enough with the details of this area).
Aug 11 2022
Noting related review: https://reviews.llvm.org/D115815 which added this variable to support this for other "external projects".
Feb 15 2022
Feb 9 2022
Feb 1 2022
Jan 31 2022
Thanks for the patch. When I originally added the multi-threaded support for the time profiler I considered adding the initialize/finish thread into the threadpool itself (llvm/lib/Support/ThreadPool.cpp). In the end I thought it was a bit messy there so just added it into LTO.cpp. With the increased use of multi-threading I think it would be worth reconsidering putting this into ThreadPool.cpp so we don't need to add this everywhere we want to trace multithreaded code. I think that the RAII code you propose will help this fit into ThreadPool.cpp neatly. For all I know there may be other problems with doing that, but I think it will be neater now this is used in more places. What do you think about trying that?
Mar 10 2021
With an additional change from sizeof(buf) to buf.size() this fixes the check-asan and check-ubsan tests.
Mar 9 2021
Mar 1 2021
Update with suggested changes to MinGW.cpp
Feb 27 2021
Feb 26 2021
Added comment on AllocatorSize.
Feb 9 2021
Feb 8 2021
Feb 5 2021
Add documentation to CMake.rst
I believe that the MCJIT failures are due to bug https:/bugs.llvm.org/show_bug.cgi?id=24978 rather than a problem in the Scudo port so I have added details of how I hit it to that bugzilla and opened two reviews to get this landed:
https://reviews.llvm.org/D96120 - [scudo] Port scudo sanitizer to Windows
https://reviews.llvm.org/D96133 - Allow building with scudo memory allocator on Windows
Feb 3 2021
I've focussed on the test test-global-init-nonzero-sm-pic.ll which fails writing to an address which (I believe) should be in the .data section but isn't.
Feb 2 2021
I managed to get this to fail in the debugger (for the cross-module-sm-pic-a.ll test):
Remove -fsanitize=scudo support for Windows in LLVM cmake, using LLVM_INTEGRATED_CRT_ALLOC instead.
Remove scudo_cxx from LLVM_INTEGRATED_CRT_ALLOC.
Dec 18 2020
Apologies for the delay, I've had other things taking my time.
Nov 9 2020
Resigning as reviewer as I also work for Sony.
Nov 5 2020
Oct 28 2020
Apologies for the delay, I've had a few other things on.
Sep 23 2020
Sep 22 2020
I'm going to concentrate on the standalone port as I think that's the way forward. If I get that working then can work through the other issues.
Sep 17 2020
Sep 15 2020
One small comment. Apart from that, LGTM.
Sep 14 2020
Re-upload patch with G LLVM Github Monorepo set.
Sep 11 2020
Is there a good sanity check that it is actually using Scudo rather than silently using the standard alloc?
Fixup scudo (sanitizer based) to work on Windows.
Aug 28 2020
Thanks for catching that.
Aug 27 2020
Fix llvm-config test.
I assume something in lit is parsing and recognizing this? Should remove that too?
I'd also like to see how they (currently supported allocators) compare vs. SCUDO and vs. tcmalloc3, if someone is willing to port those on Windows.
I've applied this to the monorepo and made a few more changes to allow it to build LLVM on Windows here: https://reviews.llvm.org/D86694
Aug 4 2020
Jul 31 2020
Thanks for your work on this. I've just tried out this version with rpmalloc (1.4.0) checked out out at the top of llvm-project.
Fixed comments and added test.
Jul 30 2020
Jul 28 2020
It looks like is causing one of the debuginfo-tests: llgdb-tests/nrvo-string.cpp to fail, run on Linux. Failure as below. I don't think the debuginfo-tests are run on any bot (but probably should be!). I bisected the failure back to this change.
Jul 23 2020
Jul 1 2020
Jun 30 2020
I notice that the improvements to rpmalloc for LLVM are still under discussion (https://github.com/mjansson/rpmalloc/issues/150) and targetted at rpmalloc v1.4.1.
Jun 23 2020
Jun 4 2020
May 29 2020
May 28 2020
May 22 2020
May 15 2020
May 14 2020
Removed excess dashes in man page. Checked with:
Change to double dashes.