forked from OSchip/llvm-project
13b8331054
Summary: The 'strong' StackProtector heuristic takes into consideration call instructions. Certain intrinsics, such as lifetime.start, can cause the StackProtector to protect functions that do not need to be protected. Specifically, a volatile variable, (not optimized away), but belonging to a stack allocation will encourage a llvm.lifetime.start to be inserted during compilation. Because that intrinsic is a 'call' the strong StackProtector will see that the alloca'd variable is being passed to a call instruction, and insert a stack protector. In this case the intrinsic isn't really lowered to a call. This can cause unnecessary stack checking, at the cost of additional (wasted) CPU cycles. In the future we should rely on TargetTransformInfo::isLoweredToCall, but as of now that routine considers all intrinsics as not being lowerable. That needs to be corrected, and such a change is on my list of things to get moving on. As a side note, the updated stack-protector-dbginfo.ll test always seems to pass. I never see the dbg.declare/dbg.value reaching the StackProtector::HasAddressTaken, but I don't see any code excluding dbg intrinsic calls either, so I think it's the safest thing to do. Reviewers: void, timshen Reviewed By: timshen Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45331 llvm-svn: 329450 |
||
|---|---|---|
| .. | ||
| Analysis | ||
| Assembler | ||
| Bindings | ||
| Bitcode | ||
| BugPoint | ||
| CodeGen | ||
| DebugInfo | ||
| Examples | ||
| ExecutionEngine | ||
| Feature | ||
| FileCheck | ||
| Instrumentation | ||
| Integer | ||
| JitListener | ||
| LTO | ||
| Linker | ||
| MC | ||
| Object | ||
| ObjectYAML | ||
| Other | ||
| SafepointIRVerifier | ||
| SymbolRewriter | ||
| TableGen | ||
| ThinLTO/X86 | ||
| Transforms | ||
| Unit | ||
| Verifier | ||
| YAMLParser | ||
| tools | ||
| .clang-format | ||
| CMakeLists.txt | ||
| TestRunner.sh | ||
| lit.cfg.py | ||
| lit.site.cfg.py.in | ||