[Win64] Insert int3 into trailing empty BBs
authorReid Kleckner <rnk@google.com>
Fri, 20 Mar 2020 21:06:27 +0000 (14:06 -0700)
committerReid Kleckner <rnk@google.com>
Mon, 23 Mar 2020 15:50:37 +0000 (08:50 -0700)
commit5ff5ddd0adc89f8827b345577bbb3e7eb74fc644
tree3b60588d5a64043e91213ebc88f2ef1d50047dad
parentebf83c36e29ab6f480860de640790795870dcccb
[Win64] Insert int3 into trailing empty BBs

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
llvm/lib/CodeGen/MIRParser/MILexer.cpp
llvm/lib/CodeGen/MIRParser/MILexer.h
llvm/lib/CodeGen/MIRParser/MIParser.cpp
llvm/lib/CodeGen/MIRPrinter.cpp
llvm/lib/Target/X86/X86.h
llvm/lib/Target/X86/X86AvoidTrailingCall.cpp
llvm/lib/Target/X86/X86TargetMachine.cpp
llvm/test/CodeGen/X86/win64-eh-empty-block-2.mir [new file with mode: 0644]
llvm/test/CodeGen/X86/win64-eh-empty-block.ll
llvm/test/CodeGen/X86/wineh-coreclr.ll