Momchil Velikov via llvm-dev
2021-Nov-21 00:06 UTC
[llvm-dev] [RFC] Asynchronous unwind tables attribute
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>
Fāng-ruì Sòng via llvm-dev
2021-Nov-21 00:33 UTC
[llvm-dev] [RFC] Asynchronous unwind tables attribute
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?