Added and implemented -asan-use-stack-safety flag, which control if ASan would use the Stack Safety results to emit less code for operations which are marked as 'safe' by the static analysis.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1496–1499 | Doesn't need nested if. I would order this as ClUseStackSafety && SSI && findAllocaForValue(Ptr) && ... (cheapest first). |
clang/include/clang/Basic/CodeGenOptions.def | ||
---|---|---|
227 | We should avoid this flag. Also clang stuff better to extract to a separate patch. | |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
813 | functionality of the pass should be the same, so I don't see why this is the fatal error. so just ignore it? btw, why don't you want to support it? | |
1262 | You can make this module pass to calculate StackSafetyGlobalAnalysis and use cached one below. |
clang/test/CodeGen/asan-stack-safety-analysis.c | ||
---|---|---|
2 | Should this file be in llvm/test/Instrumentation/ instead? Also consider porting some of the tests from HWASan (https://github.com/llvm/llvm-project/blob/main/llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll). |
clang/test/CodeGen/asan-stack-safety-analysis.c | ||
---|---|---|
2 | Uhm nevermind my first sentence, sorry about that. This is of course the right location. |
I think you also want to use SSI->isSafe(AllocaInst*) in isInterestingAlloca to prevent use-after-scope instrumentation if all accesses are safe.
clang/test/CodeGen/asan-stack-safety-analysis.c | ||
---|---|---|
2 | I've removed this file. Also added a .ll test for the internal flag. | |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
813 | I would like to support it, but I am not sure how to get an instance of StackSafetyGlobalAnalysis, because in the legacy pass manger I don't have access to AnalysisManager<Function> &AM. If you know how to make this work, please let me know. As far as the report_fatal_error my logic is that if someone sets ClUseStackSafety flag they expect it to work and if it silently doesn't it is a bad user experience. |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
813 | Maybe it would help to look at the HWASan instrumentation pass, which uses the stack safety analysis for both old and new pass managers. |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
813 | Thanks for the hint. I've used the HWAsan approach. |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
814 | usually we don't use {} for one liners. | |
1262 | It should probably be in ModuleAddressSanitizerPass, so it wll return ::all() and we don't care about invalidation. | |
1337 | INITIALIZE_PASS_DEPENDENCY(StackSafetyGlobalInfoWrapperPass) |
PTAL.
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1262 | getCachedResult uses the invalidation so I couldn't get rid of it. |
llvm/include/llvm/Analysis/StackSafetyAnalysis.h | ||
---|---|---|
93 | we still can't do that, some passes can make results irrelevant |
llvm/include/llvm/Analysis/StackSafetyAnalysis.h | ||
---|---|---|
93 | Looks like only immutable analysis can be used through proxy, and this analysis cannot be immutable. |
llvm/include/llvm/Analysis/StackSafetyAnalysis.h | ||
---|---|---|
93 | Is the problem here that an invalidated analysis needs to be rerun, and the module-to-function proxy does not know how to do that? TBH, I'm not sure how big the performance benefits of a function pass are. With the amount of time we've sunk in working around function pass requirements and I'd say just go for it. |
llvm/include/llvm/Analysis/StackSafetyAnalysis.h | ||
---|---|---|
93 | See https://reviews.llvm.org/D112732. I changed it for the new pass manager only. |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1317 | There is ::ProcessedAllocas which will be unnececary overpopulated with irrelevand allocas But please do that in a separate patch, this optimization is unrelated to SSGI |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1521 | @kstoimenov You're using the LI pointer for all IgnoreAccess calls which is causing nullptr dereference warnings in static analyzer. Should we just be using I or the dyn_cast<> pointers in each case? https://llvm.org/reports/scan-build/report-AddressSanitizer.cpp-ignoreAccess-21-f37ec0.html#EndPath |
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp | ||
---|---|---|
1521 | @kstoimenov Have you been able to check this at all please? |
We should avoid this flag.
this is internal optimization. if it works we need to make it on
for experiments -mllvm is enough.
Also clang stuff better to extract to a separate patch.