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

[Momchil Velikov via llvm-dev]

On Sun, 21 Nov 2021 at 01:02, Fāng-ruì Sòng <maskray at google.com> wrote:

> On 2021-11-21, Momchil Velikov wrote:
> >On Sun, 21 Nov 2021 at 00:33, Fāng-ruì Sòng <maskray at google.com> wrote:
> >
> >> On 2021-11-21, Momchil Velikov wrote:
> >> >         | 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?
> >>
> >
> >Because for a synchronous unwind table it makes only sense for the
> prologue
> >to be full, <min, no> is
> >unusable combination, whereas <full, no> is usable for a debugger (it's
> >basically what we have now for most backends).
>
> I wanted to ask why the prologue information has degraded from full to
> min when transiting from uwtable 1 to uwtable 2.
>
> I do not understand why moving from uwtable 1 to uwtable 2 is not
> monotonic.
>

It's not that it was degraded in the case for "uwtable=2,nounwind=1", but
that it was
"too much" for "uwtable=1,nounwind=1".  One could generate "<min,no>"
there, but that
serves no purpose - it's unusable for debugging, and for profiling, one
would
be better off with the "<min,min> variant. Also, this is the current state,
and
degrading *that* could be viewed as a regression.

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