[CFIFixup] Add frame info to the first block of each section (#113626)

Now that `-fbasic-block-sections=list` is enabled for Arm, functions may
be split aross multiple sections, and CFI information

[CFIFixup] Add frame info to the first block of each section (#113626)

Now that `-fbasic-block-sections=list` is enabled for Arm, functions may
be split aross multiple sections, and CFI information must be handled
independently for each section.

On x86, this is handled in `llvm/lib/CodeGen/CFIInstrInserter.cpp`.
However, this pass does not run on Arm, so we must add logic for it
to `llvm/lib/CodeGen/CFIFixup.cpp`.

show more ...

[CodeGen] Remove unused includes (NFC) (#115996)

Identified with misc-include-cleaner.

Reland "CFIFixup] Factor CFI remember/restore insertion into a helper (NFC)" (#113387)

The original patch (ac1a01f) dereferenced an end iterator, breaking some
tests (e.g. https://lab.llvm.org/buil

Reland "CFIFixup] Factor CFI remember/restore insertion into a helper (NFC)" (#113387)

The original patch (ac1a01f) dereferenced an end iterator, breaking some
tests (e.g. https://lab.llvm.org/buildbot/#/builders/17/builds/3116).
This updated patch only accesses the iterator when it's valid.

show more ...

Revert "Reland [CFIFixup] Factor CFI remember/restore insertion into a helper (NFC)" (#113340)

Reverts llvm/llvm-project#113328

This change breaks a number of builds (e.g
https://lab.llvm.org/bu

Revert "Reland [CFIFixup] Factor CFI remember/restore insertion into a helper (NFC)" (#113340)

Reverts llvm/llvm-project#113328

This change breaks a number of builds (e.g
https://lab.llvm.org/buildbot/#/builders/25/builds/3504), for some
reason. Reverting to do some troubleshooting.

show more ...

Reland [CFIFixup] Factor CFI remember/restore insertion into a helper (NFC) (#113328)

The previous submission looked like it triggered build failure
https://lab.llvm.org/buildbot/#/builders/17/buil

Reland [CFIFixup] Factor CFI remember/restore insertion into a helper (NFC) (#113328)

The previous submission looked like it triggered build failure
https://lab.llvm.org/buildbot/#/builders/17/builds/3116, but this
appears to be a spurious failure due to a flaky test.

show more ...

Revert "[CFIFixup] Factor CFI remember/restore insertion into a helper (NFC)" (#111168)

Reverts llvm/llvm-project#111066

This seems to be breaking some builds:
- https://lab.llvm.org/buildbot/#/

Revert "[CFIFixup] Factor CFI remember/restore insertion into a helper (NFC)" (#111168)

Reverts llvm/llvm-project#111066

This seems to be breaking some builds:
- https://lab.llvm.org/buildbot/#/builders/51/builds/4732
- https://lab.llvm.org/buildbot/#/builders/41/builds/2534
- https://lab.llvm.org/buildbot/#/builders/73/builds/6601

show more ...

[CFIFixup] Factor CFI remember/restore insertion into a helper (NFC) (#111066)

Inserting a remember/restore pair is a very clean abstraction, so we can
split the logic out into a helper function. A

[CFIFixup] Factor CFI remember/restore insertion into a helper (NFC) (#111066)

Inserting a remember/restore pair is a very clean abstraction, so we can
split the logic out into a helper function. Additionally, cleaning this up
will make it easier to add logic for handling functions that are split across
multiple sections.

show more ...

[CFIFixup] Allow function prologues to span more than one basic block (#68984)

The CFIFixup pass assumes a function prologue is contained in a single
basic block. This assumption is broken with upc

[CFIFixup] Allow function prologues to span more than one basic block (#68984)

The CFIFixup pass assumes a function prologue is contained in a single
basic block. This assumption is broken with upcoming support for stack
probing (`-fstack-clash-protection`) in AArch64 - the emitted probing
sequence in a prologue may contain loops, i.e. more than one basic
block. The generated CFG is not arbitrary though:
* CFI instructions are outside of any loops
* for any two CFI instructions of the function prologue one dominates
and is post-dominated by the other

Thus, for the prologue CFI instructions, if one is executed then all are
executed, there is a total order of executions, and the last instruction
in that order can be considered the end of the prologoue for the purpose
of inserting the initial `.cfi_remember_state` directive.

That last instruction is found by finding the first block in the
post-order traversal which contains prologue CFI instructions.

show more ...

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

This pass inserts the necessary CFI instructions to compensate for the
inconsistency of the call-frame information caused by linear (non-CG

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

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.

Reviewed By: MaskRay, danielkiss, chill

Differential Revision: https://reviews.llvm.org/D114545

show more ...

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

This pass inserts the necessary CFI instructions to compensate for the
inconsistency of the call-frame information caused by linear (non-CF

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

This pass inserts the necessary CFI instructions to compensate for the
inconsistency of the call-frame information caused by linear (non-CFG
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 that 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.

In order to accommodate backends which do not generate unwind info in
epilogues we compute an additional property "strong no call frame on
entry" which is set for the entry point of the function and for every
block reachable from the entry along a path that does not execute the
prologue. If this property holds, it takes precedence over the "has a
call frame" property.

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.

Reviewed By: MaskRay, danielkiss, chill

Differential Revision: https://reviews.llvm.org/D114545

show more ...