User Details
- User Since
- Feb 4 2016, 3:03 PM (329 w, 1 d)
Dec 9 2021
Rebase
Dec 8 2021
@browneee Thanks for the pointer!
Dec 7 2021
Oct 28 2021
@browneee Thanks! Makes sense. Is there a chance that you have an idea of the ballpark overhead of the legacy mode? I'm curious if we track N-labels, the total CPU time is generally much higher with "legacy-mode single-run with N labels" than "fast-8 mode (N/8) runs". I think there are still reasons to prefer multiple runs of fast-8 mode over the legacy mode even when the total CPU times are similar, but I wonder how bad is the overhead of expensive union operations performed by the legacy mode.
@browneee Thanks for the reply! IIUC, with non-fast mode and 16-bit shadow data, it could support 2^16 labels with a single run, so the coverage reduction is 2^16 -> 8. Do I miss something?
@gbalats @stephan.yichao.zhao Hello sorry for the late comment but I wonder what was the reason behind this change (changing taint label representation from 16-bit to 8-bit-fast only). Do we have any discussion thread from llvm-dev regarding this? Thanks!
Nov 27 2019
Sorry my bad. Seems that some powerpc tests are failing. Will revert soon and take a look.
Rebase
Nov 25 2019
Rebase
Nov 20 2019
Addressing comments from @skatkov. Thank you for your review!
Nov 19 2019
Friendly ping. @chandlerc @skatkov Can you please suggest other reviewers if you're too busy to review? Thanks!
Nov 18 2019
Rebase
Nov 14 2019
Rebase
Nov 11 2019
Add "CHECK" for the test.
Sep 4 2019
Sep 3 2019
Friendly ping!
Aug 28 2019
Aug 27 2019
Friendly ping!
Aug 23 2019
Rebase
Aug 22 2019
Hello @vitalybuka, I'm trying to land it on behalf of @sugak, but if I run arc patch it keeps failing with
Checking patch lib/sanitizer_common/symbolizer/scripts/global_symbols.txt... error: lib/sanitizer_common/symbolizer/scripts/global_symbols.txt: does not exist in index Checking patch lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh... error: lib/sanitizer_common/symbolizer/scripts/build_symbolizer.sh: does not exist in index
Aug 21 2019
Aug 15 2019
Remove redundant lines from the test.
Addressed @tejohnson's comment on the test case. Thanks!
Aug 14 2019
Aug 13 2019
@dblaikie Thank you for the comment. I encountered this problem while manipulating LLVM IR, and not sure how realistic the code can be if I synthesize one to reproduce this problem. Still, I think this is worth fixing unless we can guarantee that debug label scope won't have a DILexicalBlockFile.
@fedor.sergeev Sorry for the late reply. I missed your comment.
Avoid -O2 from the test.
Aug 9 2019
Aug 8 2019
@fedor.sergeev @yamauchi I saw your discussions over llvm-dev mailing list regarding IR printing with the new pass manager, and though this might be the reason why IR printing is not supported under new PM with clang. I would appreciate if you can take a look.
Aug 6 2019
@ldionne Got it. Thank you for your explanation!
I explained it over libcxx-dev mailing list, but our internal build system requires root permission when running the build and test from the remote container. I admit that this is not a common case, but still, wouldn't it be better to make the tests working under any circumstance?
Jun 19 2019
@dexonsmith Thank you for your reply. Are you considering the case where -print-after-all is used along with -print-* pass? If so, shouldn't we have -print-module explicitly in the test case?
Jun 18 2019
Hello, can you please explain a bit more about this change? What kind of redundant outputs avoided by this? Thanks!
Jun 5 2019
@Hahnfeld Got it. Then it seems that there's not much we can do here :(
Jun 4 2019
@Hahnfeld I'm not an OpenMP expert and don't have much strong argument here, but IMHO it might be confusing to have LLVM_ENABLE_FFI and LIBOMPTARGET_ENABLE_FFI have different default value from user's perspective. I wonder if we can set it off by default and explicitly turn it on for builds with test?
@grokos Thanks for the suggestion. What about this?
Jun 3 2019
Addressed comments from @Hahnfeld. Thanks!
May 15 2019
Use isReachableFromEntry. Thank you for the suggestion!
Thank you for your comments @efriedma! I addressed your comments and added a test case. The test segfaults clang without proposed change.
May 14 2019
Friendly ping again. This is a fix for a compiler crash.
May 3 2019
Friendly ping. Thanks!
Apr 30 2019
Friendly ping for comments. Thanks!
Apr 29 2019
Apr 25 2019
Apr 22 2019
Hello @rsmith, @wenlei and I took another look at this, and we couldn't find any use of AnonymousTagLocations outside of debug info. If that's actually the case, wouldn't it make sense to have DebugColumnInfo to control the field even if AnonymousTagLocations the part of generic printing policy?
Apr 3 2019
Apr 2 2019
@wmi Thank you for the concrete example! I think what we need for your example is context-sensitive profiling and function specialization, not inlining. Admittedly we don't have an infrastructure in LLVM to support context-sensitive profiling for non-inlined case and we don't perform context sensitive function specialization...
@wmi Thank you for the detailed explanation!
@wmi Thanks for taking a look! Performance numbers were neutral from our side.
Apr 1 2019
Check for the new pass manager added. Thanks @wmi for the comment!
@wmi Thanks for the reply! I can totally understand that entry count is not as precise as total count, but still don't think current implementation is the right way to address the issue. As I mentioned in the summary it compares two different things (instruction level counter vs function level counter), opens up a possibility for optimizing against wrong function (e.g. long and cold function), and makes it hard to find the root cause of the performance issue.
Mar 28 2019
Remove unnecessary metadata.