[PATCH] D103745: [dfsan] Add full fast8 support

twoh added a comment. @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

[PATCH] D103745: [dfsan] Add full fast8 support

twoh added a comment. @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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D103745: [dfsan] Add full fast8 support

twoh added a comment. @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! Repository:

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

This revision was automatically updated to reflect the committed changes. Closed by commit rL368804: [NewPM][PassInstrumentation] IR printing support from clang driver (authored by twoh, committed by ). Herald added a project: LLVM. Changed prior to commit:

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

twoh added a comment. @fedor.sergeev Sorry for the late reply. I missed your comment. I found that with the new pass manager module verifier is not scheduled by default, and AlwaysInlinerPass is the only one scheduled if I provide no -O option. I removed -O2 from the test command and replaced

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

twoh updated this revision to Diff 214855. twoh added a comment. Avoid -O2 from the test. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65975/new/ https://reviews.llvm.org/D65975 Files: clang/lib/CodeGen/BackendUtil.cpp

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

twoh added a comment. @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.

[PATCH] D65975: [NewPM][PassInstrumentation] IR printing support from clang driver

twoh created this revision. twoh added reviewers: fedor.sergeev, philip.pfaffe. Herald added a project: clang. Herald added a subscriber: cfe-commits. https://reviews.llvm.org/D50923 enabled the IR printing support for the new pass manager, but only for the case when `opt` tool is used as a

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh added a comment. Friendly ping for comments. Thanks! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D38061/new/ https://reviews.llvm.org/D38061 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh added a subscriber: wenlei. twoh added a comment. Herald added a subscriber: dexonsmith. Herald added a project: clang. 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,

[PATCH] D53860: [SemaCXX] Don't check base's dtor is accessible

twoh added a comment. @rsmith I see. Thank you for the clarification! Repository: rC Clang https://reviews.llvm.org/D53860 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53860: [SemaCXX] Don't check base's dtor is accessible

twoh added a comment. I think the context is Derived here. My understanding of http://wg21.link/p0968r0#2227 (in this patch's context) is that when Derived is aggregate initialized, the destructor for each element of Base is potentially invoked as well. For me it seems that the bug is

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh added a comment. @rsmith @dblaikie Thank you for the comments! It seems that this is not the appropriate way to handle the issue. I'll find different way to resolve the problem. Repository: rC Clang https://reviews.llvm.org/D38061 ___

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh added a comment. @dblaikie I see. The problem we're experiencing is that with Clang's naming scheme we end up having different function name between the original source and the preprocessed source (as macro expansion changes the column number). This doesn't work well for me if I want to

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh added a comment. @aprantl It is a debug info. If you compile test/CodeGenCXX/debug-info-anonymous.cpp file with `clang -g2 -emit-llvm -S `, you will find debug metadata something like `distinct !DISubprogram(name: "foo", linkageName: "_Z3fooIN1XUt_EEiT_" ...`, which will eventually be

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh updated this revision to Diff 170205. twoh added a comment. Remove conflict line. Repository: rC Clang https://reviews.llvm.org/D34796 Files: docs/ClangCommandLineReference.rst include/clang/Driver/Options.td include/clang/Frontend/CodeGenOptions.def lib/CodeGen/BackendUtil.cpp

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh added a comment. @joerg Sorry but I'm not sure if I understand your question. This doesn't pretend to honor source code order, but makes linker to place "hot" functions under .text.hot section (There's no guarantee of ordering between functions inside .hot.text section) while "cold"

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh updated this revision to Diff 170148. twoh added a comment. Herald added a subscriber: jfb. Rebase. Sorry I somehow missed the recent comments. I addresses @davidxl's comment on documentation. Thanks! Repository: rC Clang https://reviews.llvm.org/D34796 Files:

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh added a comment. ping! Repository: rC Clang https://reviews.llvm.org/D38061 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D38061: Set AnonymousTagLocations false for ASTContext if column info is expected not to be used

twoh updated this revision to Diff 164564. twoh edited the summary of this revision. twoh added a comment. Herald added a subscriber: cfe-commits. Addressing comments from @echristo. Reverted option name change, and added a test case. Sorry I haven't work on this code for a while so it took time

[PATCH] D37310: [Atomic] Merge alignment information from Decl and from Type when emit atomic expression.

twoh added a comment. Herald added subscribers: llvm-commits, jfb. Hello, I observed a case where atomic builtin generates libcall when the corresponding sync builtin generates an atomic instruction (https://bugs.llvm.org/show_bug.cgi?id=38846). It seems that the alignment checking for

[PATCH] D39279: Stringizing raw string literals containing newline

This revision was automatically updated to reflect the committed changes. Closed by commit rC319904: Stringizing raw string literals containing newline (authored by twoh). Changed prior to commit: https://reviews.llvm.org/D39279?vs=125564=125745#toc Repository: rC Clang

[PATCH] D39279: Stringizing raw string literals containing newline

twoh updated this revision to Diff 125564. twoh added a comment. clang-format https://reviews.llvm.org/D39279 Files: include/clang/Lex/Lexer.h lib/Lex/Lexer.cpp test/Preprocessor/macro_raw_string.cpp unittests/Lex/LexerTest.cpp Index: unittests/Lex/LexerTest.cpp

[PATCH] D39279: Stringizing raw string literals containing newline

twoh updated this revision to Diff 125563. twoh added a comment. @jkorous-apple Got it. I agree that it would be better to move the comments to the header. Will land it soon. Thanks! https://reviews.llvm.org/D39279 Files: include/clang/Lex/Lexer.h lib/Lex/Lexer.cpp

[PATCH] D39279: Stringizing raw string literals containing newline

twoh updated this revision to Diff 125368. twoh added a comment. Thanks @jkorous-apple for the comment. I think your suggestion is a more precise description for the implementation, and adjusted the comments accordingly. I intentionally didn't add the details to the comments for the header, as

[PATCH] D39279: Stringizing raw string literals containing newline

twoh added a comment. @jkorous-apple Thanks for the comments! Yeah, I was thinking of O(lenght_of_string) approach, but considering the complicatedness of the implementation (I guess the real implementation would be a bit more complex than your pseudo implementation to handle quote and '\n\r'

[PATCH] D39279: Stringizing raw string literals containing newline

twoh updated this revision to Diff 124515. twoh added a comment. Thanks @jkorous-apple for your comments. I modified the type for the variables and replaced unnecessary inserts and erases with updates. https://reviews.llvm.org/D39279 Files: include/clang/Lex/Lexer.h lib/Lex/Lexer.cpp

[PATCH] D39279: Stringizing raw string literals containing newline

twoh updated this revision to Diff 123658. twoh added a comment. Addressing @vsapsai's comments. Thank you for the suggestion! Added test case actually finds an off-by-one error in the original patch. I improved the comments as well. https://reviews.llvm.org/D39279 Files:

[PATCH] D39279: Stringizing raw string literals containing newline

twoh added a comment. Ping. Thanks! https://reviews.llvm.org/D39279 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D39279: Stringizing raw string literals containing newline

twoh updated this revision to Diff 120195. twoh added a comment. clang-format https://reviews.llvm.org/D39279 Files: lib/Lex/Lexer.cpp test/Preprocessor/macro_raw_string.cpp unittests/Lex/LexerTest.cpp Index: unittests/Lex/LexerTest.cpp

[PATCH] D39279: Stringizing raw string literals containing newline

twoh created this revision. This patch implements 4.3 of http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4220.pdf. If a raw string contains a newline character, replace each newline character with the \n escape code. Without this patch, included test case (macro_raw_string.cpp) results

[PATCH] D36474: Use the file name from linemarker for debug info if an input is preprocessed source.

This revision was automatically updated to reflect the committed changes. Closed by commit rL311037: Use the file name from linemarker for debug info if an input is preprocessed… (authored by twoh). Repository: rL LLVM https://reviews.llvm.org/D36474 Files:

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh added a comment. Friendly ping. @davidxl, I think there's no harm to make clang consistent with gcc for compiler options, and I wonder if you have any concerns that I may miss. Thanks! https://reviews.llvm.org/D34796 ___ cfe-commits mailing

[PATCH] D36474: Use the file name from linemarker for debug info if an input is preprocessed source.

twoh added a comment. Ping. Thanks! https://reviews.llvm.org/D36474 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D36474: Use the file name from linemarker for debug info if an input is preprocessed source.

twoh updated this revision to Diff 110237. twoh added a comment. Addressing dblaikie's comments. Thanks! https://reviews.llvm.org/D36474 Files: lib/CodeGen/CGDebugInfo.cpp test/CodeGen/debug-info-preprocessed-file.i Index: test/CodeGen/debug-info-preprocessed-file.i

[PATCH] D36474: Use the file name from linemarker for debug info if an input is preprocessed source.

twoh updated this revision to Diff 110230. twoh added a comment. Relocate. https://reviews.llvm.org/D36474 Files: lib/CodeGen/CGDebugInfo.cpp test/CodeGen/debug-info-preprocessed-file.i Index: test/CodeGen/debug-info-preprocessed-file.i

[PATCH] D36474: Use the file name from linemarker for debug info if an input is preprocessed source.

twoh created this revision. Herald added a subscriber: aprantl. Even in the case of the input file is a preprocessed source, clang uses the file name of the preprocesses source for debug info (DW_AT_name attribute for DW_TAG_compile_unit). However, gcc uses the file name specified in the first

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh added a comment. I think it is generally good to match what GCC does to not to confuse people. https://reviews.llvm.org/D34796 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh updated this revision to Diff 108967. twoh added a comment. Update documentation. Please let me know if I need to update other documents as well. Thanks! https://reviews.llvm.org/D34796 Files: docs/ClangCommandLineReference.rst include/clang/Driver/Options.td

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh added a comment. Ping. Thanks! https://reviews.llvm.org/D34796 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34796: upporting -f(no)-reorder-functions flag, clang side change

twoh created this revision. When profile data is given, .hot/.unlikely section prefix is added to hot/cold functions for linker to improve code locality. GCC controls this behavior with '-f(no)-reorder-functions' flag, while LLVM uses opt tool option '-profile-guided-section-prefix=true/false'.

[PATCH] D30663: Use filename in linemarker when compiling preprocessed source (Revised)

This revision was automatically updated to reflect the committed changes. Closed by commit rL297194: Use filename in linemarker when compiling preprocessed source (Revised) (authored by twoh). Changed prior to commit: https://reviews.llvm.org/D30663?vs=90735=90912#toc Repository: rL LLVM

[PATCH] D30663: Use filename in linemarker when compiling preprocessed source (Revised)

twoh updated this revision to Diff 90735. twoh added a comment. Herald added a subscriber: mehdi_amini. addressing comments from @inglorion https://reviews.llvm.org/D30663 Files: include/clang/Frontend/FrontendOptions.h lib/Frontend/FrontendAction.cpp test/Frontend/preprocessed-input.i

[PATCH] D30663: Use filename in linemarker when compiling preprocessed source (Revised)

twoh added inline comments. Comment at: test/Frontend/preprocessed-input.c:3 +// RUN: %clang -emit-llvm -S -o - %t.i | FileCheck %s +// CHECK: source_filename = {{.*}}preprocessed-input.c"{{$}} inglorion wrote: > Actually, I think you don't even have to run the

[PATCH] D30663: Use filename in linemarker when compiling preprocessed source (Revised)

twoh created this revision. This is a revised version of https://reviews.llvm.org/D28796. Included test is changed to resolve the target compatibility issue reported (https://reviews.llvm.org/rL293032). https://reviews.llvm.org/D30663 Files: include/clang/Frontend/FrontendOptions.h

[PATCH] D30591: Introduce the feature "linux" for tests only for linux

twoh abandoned this revision. twoh added a comment. @inglorion That makes a lot of sense. Maybe we don't even need -g, because -S -emit-llvm shows source_filename. I'll run some more experiments with relpath/abspath and debug locations, and submit a revised patch. Thanks for the comment!

[PATCH] D30591: Introduce the feature "linux" for tests only for linux

twoh created this revision. This feature is needed to re-enable https://reviews.llvm.org/rL293004, which resembles gcc's behavior in finding the input file name from a preprocessed source. The patch has been reverted in https://reviews.llvm.org/rL293032, because the test checks FILE symbol of

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

This revision was automatically updated to reflect the committed changes. Closed by commit rL295779: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters (authored by twoh). Changed prior to commit: https://reviews.llvm.org/D3?vs=88584=89285#toc Repository: rL LLVM

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

twoh added a comment. @eric_niebler Do you want any more experiments with this patch? I think Windows machines not printing warnings/fixits for absolute path is a separate issue with this. https://reviews.llvm.org/D3 ___ cfe-commits mailing

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

twoh added inline comments. Comment at: test/Lexer/case-insensitive-include-pr31836.sh:6 +// RUN: touch %T/case-insensitive-include-pr31836.h +// RUN: echo "#include \"%T/Case-Insensitive-Include-Pr31836.h\"" | %clang_cc1 -E - 2>&1 | FileCheck %s + karies

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

twoh added a comment. @eric_niebler I just tried it on Windows machine, and it just succeeded with no warnings/fix-it. Is that expected? https://reviews.llvm.org/D3 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

twoh updated this revision to Diff 88584. twoh added a comment. Make it explicit that the test doesn't support windows. @eric_niebler, my original intention was avoiding use of platform-dependent path separator, but now made it explicit that the test is not for windows, it should be okay to use

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

twoh created this revision. This is a patch for PR31836. As the bug replaces the path separators in the included file name with the characters following them, the test script makes sure that there's no "Ccase-insensitive-include-pr31836.h" in the warning message.