We emit 1 compact unwind encoding per function, and this can’t represent
the varying stack pointer that will be generated by X86CallFrameOptimization.
Disable the optimization on Darwin.
(It might be possible to split the function into multiple ranges
and emit 1 compact unwind info per range. The compact unwind emission
code isn’t ready for that and this kind of info certainly isn’t
tested/used anywhere. It might be worth exploring this path if we want
to get the space savings at some point though)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249694
91177308-0d34-0410-b5e6-
96231b3b80d8
#include "llvm/ADT/Statistic.h"
#include "llvm/CodeGen/MachineFunctionPass.h"
#include "llvm/CodeGen/MachineInstrBuilder.h"
+#include "llvm/CodeGen/MachineModuleInfo.h"
#include "llvm/CodeGen/MachineRegisterInfo.h"
#include "llvm/CodeGen/Passes.h"
#include "llvm/IR/Function.h"
if (STI.is64Bit())
return false;
+ // We can't encode multiple DW_CFA_GNU_args_size in the compact
+ // unwind encoding that Darwin uses.
+ if (STI.isTargetDarwin() && !MF.getMMI().getLandingPads().empty())
+ return false;
+
// You would expect straight-line code between call-frame setup and
// call-frame destroy. You would be wrong. There are circumstances (e.g.
// CMOV_GR8 expansion of a select that feeds a function call!) where we can
; RUN: llc < %s -mtriple=i686-pc-linux -filetype=obj | llvm-readobj -s -sr -sd | FileCheck %s
+; RUN: llc < %s -mtriple=i686-darwin-macosx10.7 -filetype=obj | llvm-readobj -sections | FileCheck -check-prefix=DARWIN %s
+
+; On darwin, check that we manage to generate the compact unwind section
+; DARWIN: Name: __compact_unwind
+; DARWIN: Segment: __LD
; CHECK: Index: 8
; CHECK-NEXT: Name: .eh_frame (41)