Rebase

@browneee Thanks for the pointer!

@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!

Sorry my bad. Seems that some powerpc tests are failing. Will revert soon and take a look.

Rebase

Rebase

Addressing comments from @skatkov. Thank you for your review!

Friendly ping. @chandlerc @skatkov Can you please suggest other reviewers if you're too busy to review? Thanks!

Rebase

Rebase

Add "CHECK" for the test.

Friendly ping!

Friendly ping!

Rebase

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

Remove redundant lines from the test.

Addressed @tejohnson's comment on the test case. Thanks!

@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.

@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.

@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?

@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?

Hello, can you please explain a bit more about this change? What kind of redundant outputs avoided by this? Thanks!

@Hahnfeld Got it. Then it seems that there's not much we can do here :(

@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?

Addressed comments from @Hahnfeld. Thanks!

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.

Friendly ping again. This is a fix for a compiler crash.

Friendly ping. Thanks!

Friendly ping for comments. Thanks!

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?

@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.

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.

Remove unnecessary metadata.