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

[Fāng-ruì Sòng via llvm-dev]

On 2021-11-21, Momchil Velikov wrote:
>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.

uwtable 1/nounwind 1: <full,no>
uwtable 2/nounwind 1: <min,min>

Why is there a full->min transition for the generated prologue?