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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Mar 26 19:01:29 PDT 2022


MaskRay added a comment.

> there is a single basic block, containing the function prologue

There is the current limitation of LLVM's shrink wrapping.
I think GCC can place a prologue in multiple basic blocks.
It seems that the algorithm can process multiple prologues with some conditions.

If we consider (a) a prologue, (b) a epilogue, or (c) a region delimitered by a pair of prologue/epilogue, as a vertex in a graph,
the algorithm can handle any linear basic block layout which is a pre-order traversal.

Conceptually, the basic blocks can be partitioned into multiple segments where each segment describes a prologue and its associated epilogues/inner regions.
For each segment, the prologue must precede all its associated epilogues.

> "prologue and epilogue blocks are outside of any loops"

I think this is naturally satisfied and does not need to be emphasized here.
I think the algorithm can handle prologue and epilogue in a loop (a prologue vertex cannot be recursively entered)

> "has a call frame", if the function has executed the prologue, or has not executed any epilogue

or => "... and has not executed any epilogue"

> 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.

"layout order" seems to suggest the linear placement order.
Here we seem to suggest the order related to reachability, but I do not know the appropriate term.


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

https://reviews.llvm.org/D114545



More information about the llvm-commits mailing list