[llvm-dev] [RFC] Asynchronous unwind tables attribute

[Momchil Velikov via llvm-dev]

On Sat, 20 Nov 2021 at 19:12, Fāng-ruì Sòng <maskray at google.com> wrote:
>
> On 2021-11-20, Momchil Velikov wrote:
> >How about instead we exchange the meaning of 2 and 3 so we get
> >  - 1, sync unwind tables
> >  - 2, "minimal" async unwind tables
> >  - 3, full async unwind tables
> >Then on the principle that we should always emit CFI information that the
> >`uwtable` requested
> >(as it may be an ABI mandate), possibly optimised, depending on the
> >`nounwind` attribute, we would get:
> >
> >          | nounwind 0           |  nounwind 1
> >----------+----------------------+--------------
> >uwtable 0 | sync, full           |  no CFI
> >----------+----------------------+--------------
> >uwtable 1 | sync, full           |  sync, full
> >----------+----------------------+--------------
> >uwtable 2 | async, full prologue,|
> >          | mininal epilogue     |  async, min
> >----------+----------------------+--------------
> >uwtable 3 | async, full          |  async, full
> >
> >as a starting point, and then backends may choose any of the entries
> >in the following rows of the same column, as a QOI decision.
>
> I have trouble understanding "min" in the uwtable 2 row.
> What does it mean?

"min" would be minimal unwind information, suitable just for getting the
list of callers.
Thus, if we request "minimal" asynchronous unwind tables, and a function
has the
"nounwind" attribute, then we can fully honour that request and emit CFI
instructions
for CFA and PC only, both in the prologue and the epilogue, whereas if we
don't have
the "nounwind" attribute, there's no other option other than to also
include CFI instructions
for CSRs as well, but only in the prologue, the epilogue stays the same.

> As IR attributes, I'd hope the behavior is strictly monotonic in every
> dimensions. I.e. If uwtable A provides some information, I'd expect that
> uwtable B provides at least the same amount of information if A < B.

I'm not sure how useful would that be, as the sensible end result would also
depend on the "nounwind" attribute.

Also, I'm basically equating "asynchronous unwind info" with generating CFI
instructions for epilogues. In principle, CFI for prologues could be
different
and slightly more compact if it does not need to be instruction precise, but
as a practical matter, I doubt extra complexity in implementation warrants
supporting anything but instruction precise unwinding, once a backend
implements it.

So, the table above is no good, better presented would be like:

         | nounwind 0  |  nounwind 1
----------+-------------+--------------
uwtable 0 | <full,no>   |  <no,no>
----------+-------------+--------------
uwtable 1 | <full,no>   |  <full,no>
----------+-------------+--------------
uwtable 2 | <full,min> | <min, min>
----------+-------------+--------------
uwtable 3 | <full,full> |  <full,full>

where
 - "full" means full unwind info - CFA, CSRs, return address
 - "min" is minimal, sans CSRs,
 - "no" is, well, no unwind info and
 - "<p,e>" is the kind generated for prologues and epilogues, respectively.

~chill
--
Compiler scrub, Arm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211121/d686c8e6/attachment.html>