- User Since
- Feb 9 2017, 3:56 PM (193 w, 1 d)
Aug 18 2020
Aug 10 2020
This looks good to me FWIW. I'd prefer if someone more experienced with the project would accept it, though.
Aug 6 2020
Apr 7 2020
Mar 17 2020
Thanks for the note about the flags. We have tried both of them, and any (or both) of them being present causes the regression to go away, so that unblocks us while we work on producing a proper test case.
Mar 16 2020
We're seeing some large performance regressions on Eigen (http://eigen.tuxfamily.org/) running on haswell and skylake machines with this patch. Could you please revert it?
Mar 12 2020
Mar 11 2020
Thanks for doing the extra work of adding a test. Just one final nit.
I think it looks good now. My only issue is that it seems to rely on a couple of glibc-specific features: glibc modifying the fields adds and subs in dl_phdr_info when loading/unloading libraries (which this patch uses to know when to invalidate the cache), and dl_iterate_phdr holding a lock (which the patch relies on to avoid races while accessing the cache). What other libc implementations do we support? Do they share these behaviors we rely on here?
Mar 10 2020
Mar 9 2020
Looks good to me.
Mar 6 2020
As far as I can tell (there is indeed a lot of ifdeffing going on, please keep an eye on the buildbots) this change seems to be both NFC and an improvement to the previous state, so LGTM.
Feb 18 2020
Feb 4 2020
Could anyone please take another look at this?
Jan 14 2020
Dec 3 2019
Nov 18 2019
I found a clang crash that seems to be caused by this patch. Here's a reduced test case:
Nov 15 2019
Sorry it took me so long to respond to this. Please take another look.
Oct 14 2019
Oct 10 2019
Oct 3 2019
Re-made the test asm file starting with a -O2 compilation to avoid some unnecessary code.
Sep 6 2019
It's just that it seemed weird/hacky to use asm just to stick assembler directives in the middle of the generated code instead of actual assembly, so I generated an assembly version and cleaned it up a bit. I'm happy to go back to the original shorter C++ version if that's not a concern.
Added a test case that seems to work well with the existing testing setup if I rebuild LLVM with ASan enabled. I have checked out other usages of .cfi_* directives in other LLVM assembly test files and they seem to run them through some llvm tool with -triple <something including linux>, so I have added a REQUIRES: linux line to avoid breakage.
Aug 30 2019
Looking into how to add a test now. I'm not familiar at all with libunwind code, so I have no idea how to cause this leak to happen from the outside (and then the test would only work when running under asan). Any pointers would be much appreciated.
Aug 28 2019
Aug 2 2019
FYI we have detected a 2-3% performance regression on Haswell machines in test-suite/MicroBenchmarks/ImageProcessing/Interpolation that seems to be caused by this commit.
Jun 7 2019
Jun 6 2019
Hm, I just realized I'm undoing https://reviews.llvm.org/D58883.
About %T not working for "process launch", what about something like RUN: %lldb -b --one-line-before-file "process launch --stdout %T/x86-zmm-write.out" -s %s %t and then FileCheck-ing?
May 23 2019
May 22 2019
May 9 2019
Removed trailing blank lines from test case, will commit now. Thanks for the review!
Added a new test that checks that, when a full path to a compiler is specified:
May 8 2019
Apr 26 2019
Apr 22 2019
Thanks for the fix!
Apr 16 2019
Thanks! Please let me know if it happens again and I'll try my best to debug it.
Apr 3 2019
Increased wait time in test binary for TestVSCode_attach.py from 5 to 10 seconds.
Apr 2 2019
Apr 1 2019
Mar 26 2019
Mar 14 2019
I considered assigning it to a std::string, but GetCString() can return a null pointer and I'm not sure you can construct a std::string directly from that.