[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 th

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

browneee added a comment. Sorry, I was thinking/describing fast-16 to fast-8. The same reasons apply for legacy mode (2^16 labels) to fast-8. - simplify code (smaller codesize overhead) - share more code and shadow/origin memory layout with MSan (which also has a 1:1 shadow) - reduce memory ove

[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 https://reviews

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

browneee added a subscriber: kcc. browneee added a comment. In D103745#3094831 , @twoh wrote: > @gbalats @stephan.yichao.zhao Hello sorry for the late comment but I wonder > what was the reason behind this change (changing taint label representation > f

[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: r

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

gbalats added inline comments. Comment at: llvm/test/Instrumentation/DataFlowSanitizer/external_mask.ll:6 define i32 @test(i32 %a, i32* nocapture readonly %b) #0 { -; CHECK: @"dfs$test" -; CHECK: %[[RV:.*]] load{{.*}}__dfsan_shadow_ptr_mask -; CHECK: ptrtoint i32* {{.*}} to i64

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

browneee accepted this revision. browneee added inline comments. Comment at: llvm/test/Instrumentation/DataFlowSanitizer/external_mask.ll:6 define i32 @test(i32 %a, i32* nocapture readonly %b) #0 { -; CHECK: @"dfs$test" -; CHECK: %[[RV:.*]] load{{.*}}__dfsan_shadow_ptr_mask -; C

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

gbalats marked an inline comment as done. gbalats added inline comments. Comment at: clang/docs/DataFlowSanitizer.rst:172-178 assert(ij_label == 3); // Verifies all of the above +// Or, equivalently: +assert(dfsan_has_label(ij_label, i_label)); +assert(dfsan_h

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

stephan.yichao.zhao added a comment. How did we fix that alignment error from compiler-rt/test/dfsan/origin_ldst.c? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103745/new/ https://reviews.llvm.org/D103745

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

stephan.yichao.zhao added inline comments. Comment at: clang/docs/DataFlowSanitizer.rst:172-178 assert(ij_label == 3); // Verifies all of the above +// Or, equivalently: +assert(dfsan_has_label(ij_label, i_label)); +assert(dfsan_has_label(ij_label, j_label));

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

stephan.yichao.zhao added a comment. The failed test cases from x64 debian > libFuzzer.libFuzzer::* seem related. They still use -dfsan-fast-16-labels. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D103745/new/ https://reviews.llvm.org/D103745 ___