[MC] Don't emit redundant compact unwind entries

[int3]

Summary

If there's no DWARF instructions, personality, or LSDA, I don't think
there's a need to emit a CU entry either. This canonicalization of
unwind info allows link-time code folding to fold more functions (since
functions with trivial unwind info are now obviously identical to
functions with the same code but with no unwind info).

[int3]

update

[steven_wu]

If a function do not have unwind info, you cannot throw anything across the frame. That will be a very harsh behavior for any programmer who does not think about exception for all the code they use.

For example:

func call_back_throw() <--- with unwind info
func library_code() <--- no dwarf, no LSDA
func catch_site() <--- nope, cant catch anything

If you want to avoid unwind table, just have something like -fno-unwind-tables so they are nounwind in IR in the first place.

[int3]

Oh, thanks for your example, I wasn't aware of that. Just to make sure I understand, if a function has an encoding of 0x0 in the final binary's __unwind_info, that means you cannot throw anything across the frame?

Also, the x86_64 MC backend is a lot more aggressive about omitting unwind info (https://discourse.llvm.org/t/does-it-make-sense-for-a-function-to-have-a-personality-lsda-if-it-has-no-other-unwind-info-mach-o/65490). Curious if you have thoughts on that. Is that a bug in x86_64, or does the arm64 unwinder work differently?

[steven_wu]

Oh, thanks for your example, I wasn't aware of that. Just to make sure I understand, if a function has an encoding of 0x0 in the final binary's __unwind_info, that means you cannot throw anything across the frame?

I am not an expert in the area but I would believe that is the case. You can dig through libunwind in llvm to see the implementation over there.

Also, the x86_64 MC backend is a lot more aggressive about omitting unwind info (https://discourse.llvm.org/t/does-it-make-sense-for-a-function-to-have-a-personality-lsda-if-it-has-no-other-unwind-info-mach-o/65490). Curious if you have thoughts on that. Is that a bug in x86_64, or does the arm64 unwinder work differently?

Looks like x86 backend emit __eh_frame instead?

[int3]

Looks like x86 backend emit __eh_frame instead?

Yep, you're right, thanks!

llvm/lib/MC/MCStreamer.cpp

 }
 
 void MCStreamer::emitRawComment(const Twine &T, bool TabPrefix) {}
 
 void MCStreamer::addExplicitComment(const Twine &T) {}
 void MCStreamer::emitExplicitComments() {}
 
 void MCStreamer::generateCompactUnwindEncodings(MCAsmBackend *MAB) {
-  for (auto &FI : DwarfFrameInfos)
+  for (auto &FI : DwarfFrameInfos) {
+    if (!MAB || FI.Instructions.empty() && !FI.Personality && !FI.Lsda)
+      continue;
     FI.CompactUnwindEncoding =
-        (MAB ? MAB->generateCompactUnwindEncoding(FI.Instructions) : 0);
+        MAB->generateCompactUnwindEncoding(FI.Instructions);
+  }
 }
 
 /// EmitIntValue - Special case of EmitValue that avoids the client having to
 /// pass in a MCExpr for constant integers.
 void MCStreamer::emitIntValue(uint64_t Value, unsigned Size) {
   assert(1 <= Size && Size <= 8 && "Invalid size");
   assert((isUIntN(8 * Size, Value) || isIntN(8 * Size, Value)) &&
          "Invalid size");

llvm/test/ExecutionEngine/JITLink/AArch64/MachO_arm64_compact_unwind.s

 # REQUIRES: asserts
 # RUN: llvm-mc -triple=arm64-apple-ios -filetype=obj -o %t %s
 # RUN: llvm-jitlink -noexec -debug-only=jitlink %t 2>&1 | FileCheck %s
 #
 # Check that splitting of compact-unwind sections works.
 #
 # CHECK: splitting {{.*}} __LD,__compact_unwind containing 1 initial blocks...
 # CHECK:   Splitting {{.*}} into 1 compact unwind record(s)
 # CHECK:     Updating {{.*}} to point to _main {{.*}}
 
   .section  __TEXT,__text,regular,pure_instructions
   .globl  _main
   .p2align  2
 _main:
   .cfi_startproc
+  .cfi_def_cfa_offset 16
   ret
   .cfi_endproc
 
 .subsections_via_symbols
 

llvm/test/MC/AArch64/arm64-leaf-compact-unwind.s

 // RUN: llvm-mc -triple=arm64-apple-ios -filetype=obj < %s | \
 // RUN: llvm-objdump --macho --unwind-info - | \
 // RUN: FileCheck %s
 //
 // rdar://13070556
 
 # CHECK:      Contents of __compact_unwind section:
 # CHECK-NEXT:   Entry at offset 0x0:
-# CHECK-NEXT:     start:                0x0 ltmp0
-# CHECK-NEXT:     length:               0x8
-# CHECK-NEXT:     compact encoding:     0x02000000
-# CHECK-NEXT:   Entry at offset 0x20:
 # CHECK-NEXT:     start:                0x8 _foo2
 # CHECK-NEXT:     length:               0x40
 # CHECK-NEXT:     compact encoding:     0x02009000
-# CHECK-NEXT:   Entry at offset 0x40:
+# CHECK-NEXT:   Entry at offset 0x20:
 # CHECK-NEXT:     start:                0x48 _foo3
 # CHECK-NEXT:     length:               0xd4
 # CHECK-NEXT:     compact encoding:     0x0200400f
-# CHECK-NEXT:   Entry at offset 0x60:
+# CHECK-NEXT:   Entry at offset 0x40:
 # CHECK-NEXT:     start:                0x11c _foo4
 # CHECK-NEXT:     length:               0x54
 # CHECK-NEXT:     compact encoding:     0x02021010
 
   .section  __TEXT,__text,regular,pure_instructions
   .globl  _foo1
   .align  2
 _foo1:                                  ; @foo1

llvm/test/MC/AArch64/arm64_32-compact-unwind.s

 ; RUN: llvm-mc -triple=arm64_32-ios7.0 -filetype=obj %s -o %t
 ; RUN: llvm-objdump -s %t | FileCheck %s
 
 ; The compact unwind format in ILP32 mode is pretty much the same, except
 ; references to addresses (function, personality, LSDA) are pointer-sized.
 
 ; CHECK: Contents of section __LD,__compact_unwind:
-; CHECK-NEXT:  0004 00000000 04000000 00000002 00000000
+; CHECK-NEXT:  0004 00000000 04000000 00100002 00000000
 ; CHECK-NEXT:  0014 00000000
         .globl  _test_compact_unwind
         .align  2
 _test_compact_unwind:
         .cfi_startproc
+        .cfi_def_cfa_offset 16
         ret
         .cfi_endproc