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

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>

On Sun, Nov 21, 2021 at 2:11 AM Momchil Velikov
<momchil.velikov at gmail.com> wrote:
>
> 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.
The argument with keeping <full,no> for "uwtable=1,nounwind=1"
as the
current state is fine.
But then why is <min,min> for "unwtable=2,nounwind=1" not a
problem
for debugging?