[PATCH] D114545: [CodeGen] Async unwind - add a pass to fix CFI information

Momchil Velikov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 24 10:32:06 PST 2021


chill created this revision.
chill added reviewers: t.p.northover, efriedma, MaskRay, xgupta.
Herald added subscribers: ctetreau, hiraditya, mgorny.
chill requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This pass inserts the necessary CFI instructions to compensate for the
inconsistency of the call-frame information caused by linear (non-CGA
aware) nature of the unwind tables.

Unlike the `CFIInstrInserer` pass, this one almost always emits only
`.cfi_remember_state`/`.cfi_restore_state`, which results in smaller
unwind tables and also transparently handles custom unwind info
extensions like CFA offset adjustement and save locations of SVE
registers.

This pass takes advantage of the constraints taht LLVM imposes on the
placement of save/restore points (cf. `ShrinkWrap.cpp`):

- there is a single basic block, containing the function prologue
- possibly multiple epilogue blocks, where each epilogue block is complete and self-contained, i.e. CSR restore instructions (and the corresponding CFI instructions are not split across two or more blocks.
- prologue and epilogue blocks are outside of any loops

Thus, during execution, at the beginning and at the end of each basic
block the function can be in one of two states:

- "has a call frame", if the function has executed the prologue, or has not executed any epilogue
- "does not have a call frame", if the function has not executed the prologue, or has executed an epilogue

These properties can be computed for each basic block by a single RPO
traversal.

>From the point of view of the unwind tables, the "has/does not have
call frame" state at beginning of each block is determined by the
state at the end of the previous block, in layout order.

Where these states differ, we insert compensating CFI instructions,
which come in two flavours:

- CFI instructions, which reset the unwind table state to the initial one.  This is done by a target specific hook and is expected to be trivial to implement, for example it could be:

  .cfi_def_cfa <sp>, 0
  .cfi_same_value <rN>
  .cfi_same_value <rN-1>
  ...

where `<rN>` are the callee-saved registers.

- CFI instructions, which reset the unwind table state to the one created by the function prologue. These are the sequence:

  .cfi_restore_state
  .cfi_remember_state

In this case we also insert a `.cfi_remember_state` after the
last CFI instruction in the function prologue.


https://reviews.llvm.org/D114545

Files:
  llvm/include/llvm/CodeGen/CFIFixup.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinterDwarf.cpp
  llvm/lib/CodeGen/CFIFixup.cpp
  llvm/lib/CodeGen/CMakeLists.txt
  llvm/lib/CodeGen/TailDuplicator.cpp
  llvm/lib/Target/AArch64/AArch64.h
  llvm/lib/Target/AArch64/AArch64CFIFixup.cpp
  llvm/lib/Target/AArch64/AArch64CFIFixup.h
  llvm/lib/Target/AArch64/AArch64TargetMachine.cpp
  llvm/lib/Target/AArch64/CMakeLists.txt
  llvm/test/CodeGen/AArch64/O0-pipeline.ll
  llvm/test/CodeGen/AArch64/O3-pipeline.ll
  llvm/test/CodeGen/AArch64/arm64-fp128.ll
  llvm/test/CodeGen/AArch64/call-rv-marker.ll
  llvm/test/CodeGen/AArch64/cfi-fixup.ll
  llvm/test/CodeGen/AArch64/cfi-fixup.mir
  llvm/test/CodeGen/AArch64/combine-comparisons-by-cse.ll
  llvm/test/CodeGen/AArch64/cond-br-tuning.ll
  llvm/test/CodeGen/AArch64/csr-split.ll
  llvm/test/CodeGen/AArch64/merge-store-dependency.ll
  llvm/test/CodeGen/AArch64/nomerge.ll
  llvm/test/CodeGen/AArch64/optimize-cond-branch.ll
  llvm/test/CodeGen/AArch64/stack-guard-sysreg.ll
  llvm/test/CodeGen/AArch64/unwind-preserved.ll
  llvm/test/Transforms/CodeGenPrepare/AArch64/large-offset-gep.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D114545.389542.patch
Type: text/x-patch
Size: 50502 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211124/03004596/attachment-0001.bin>


More information about the llvm-commits mailing list