forked from OSchip/llvm-project
5ff5ddd0ad
Otherwise, the Win64 unwinder considers direct branches to such empty trailing BBs to be a branch out of the function. It treats such a branch as a tail call, which can only be part of an epilogue. If the unwinder misclassifies such a branch as part of the epilogue, it will fail to unwind the stack further. This can lead to bad stack traces, or failure to handle exceptions properly. This is described in https://llvm.org/PR45064#c4, and by the comment at the top of the X86AvoidTrailingCallPass.cpp file. It should be safe to insert int3 for such blocks. An empty trailing BB that reaches this pass is pretty much guaranteed to be unreachable. If a program executed such a block, it would fall off the end of the function. Most of the complexity in this patch comes from threading through the "EHFuncletEntry" boolean on the MIRParser and registering the pass so we can stop and start codegen around it. I used an MIR test because we should teach LLVM to optimize away these branches as a follow-up. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D76531 |
||
|---|---|---|
| .. | ||
| Analysis | ||
| Assembler | ||
| Bindings | ||
| Bitcode | ||
| BugPoint | ||
| CodeGen | ||
| DebugInfo | ||
| Demangle | ||
| Examples | ||
| ExecutionEngine | ||
| Feature | ||
| FileCheck | ||
| IR | ||
| Instrumentation | ||
| Integer | ||
| JitListener | ||
| LTO | ||
| Linker | ||
| MC | ||
| MachineVerifier | ||
| Object | ||
| ObjectYAML | ||
| Other | ||
| Reduce | ||
| SafepointIRVerifier | ||
| Support | ||
| SymbolRewriter | ||
| TableGen | ||
| ThinLTO/X86 | ||
| Transforms | ||
| Unit | ||
| Verifier | ||
| YAMLParser | ||
| tools | ||
| .clang-format | ||
| CMakeLists.txt | ||
| TestRunner.sh | ||
| lit.cfg.py | ||
| lit.site.cfg.py.in | ||