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

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

On Sun, Nov 21, 2021 at 10:47 AM Momchil Velikov
<momchil.velikov at gmail.com> wrote:
>
> On Sun, 21 Nov 2021 at 18:22, Fāng-ruì Sòng <maskray at google.com> wrote:
> > But then why is <min,min> for "unwtable=2,nounwind=1" not a problem
> > for debugging?
>
> Well, it is, but it's a different use case. A user chooses whatever
> suits their needs.
> If they need debugging they can choose either "uwtable=1" or
> "uiwtable=3". If they need
> profiling they can choose "uwtable=2" or "uwtable=3".  If they don't
> need either, they can choose "uwtable=0".
>
> --
> Compiler scrub, Arm

Got it. So there are indeed 3 dimensions as I think.

(a) nounwind: raise exceptions or not
(b) uwtable: generate additional information even if nounwind is
specified: none, sync, async
(c) number of registers:  pc(or link register)/sp/(maybe fp), or full
(most changed callee-saved registers)

The uwtable=0,1,2,3 scale combines (b) and (c), but the (b)x(c)
possibilities cannot be linearized.
What I wondered is whether we can make (c) an llvm::TargetOptions::*
option like FunctionSections/DataSections, then (b) can be linearized
(none,sync,async).
The downsize is that in LTO builds, one cannot indicate the intent
that a.o wants a subset of registers while b.o wants a full set.
My feeling is that users wanting mix-and-match (c) behavior is rare,
therefore an llvm::TargetOptions::* option can serve them well.
If the requirement actually becomes real, we can introduce new
function attributes.

If we start with the non-linear uwtable=0,1,2,3, then we cannot fix it
in the future.