[PATCH] D87370: [llvm-readobj] [ARMWinEH] Print ARM64 packed unwind info

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: llvm/test/tools/llvm-readobj/COFF/arm64-packed-unwind.s:59
+// CHECK-NEXT:     Prologue [
+// CHECK-NEXT:       sub sp, sp, #0
+// CHECK-NEXT:       stp d10, d11, [sp, #24]
----------------
"sub sp, sp, #0" is a no-op.  Is that really the right interpretation?  


================
Comment at: llvm/tools/llvm-readobj/ARMWinEHPrinter.cpp:1191
+      SW.startLine() << format("stp x0, x1, [sp, #%d]\n", IntSZ + FpSZ);
+    else // This case isn't documented
+      SW.startLine() << format("stp x0, x1, [sp, #-%d]!\n", SavSZ);
----------------
mstorsjo wrote:
> efriedma wrote:
> > I don't understand the `if (RF.RegI() + RF.RegF() > 0)` check; if the function homes registers, the homing region have to be contiguous.
> > 
> > That said, the compiler could stick any sequence of four instructions here, really; maybe we should just print them as nops.
> Normally, if RegI or RegF are nonzero (that was just an obscure way of writing `if (RegI() > 0 || RegF() > 0)`), either of them will have done the predecrement, e.g. like in the testcase for func5, in forward order:
> ```
>        str x19, [sp, #-80]!
>        stp x0, x1, [sp, #8]
>        stp x2, x3, [sp, #24]
>        stp x4, x5, [sp, #40]
>        stp x6, x7, [sp, #56]
> ```
> 
> However, if both RegI and RegF are zero (and CR != 1, I think I haven't covered that case), neither of the instructions that normally would have done the predecrement by decrementing the stack by SavSZ (which includes the homing area) have existed, and the only sensible way of writing that prologue would be
> ```
>        stp x0, x1, [sp, #-64]!
>        stp x2, x3, [sp, #16]
>        stp x4, x5, [sp, #32]
>        stp x6, x7, [sp, #48]
>        sub sp, sp, #LocSZ
> ```
> (which is func6 in the testcase). For that case, one would have SavSZ = 64 and LocSZ = FrameSize - 64, and the final stack decrement doesn't include the 64 bytes that are expected to have been decremented as SavSZ. So for that case, the equivalent unwinding opcodes would be "alloc_s 64, nop, nop, nop", instead of four nops.
> 
> Technically yes, the compiler could stick any sequence of instructions there as it just is nops, unwidning-wise, but I think printing this makes it clearer, as to where exactly the homing region is relative to the stack pointer.
Hmm.  I guess that makes sense.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87370/new/

https://reviews.llvm.org/D87370