[llvm-dev] RFC] Shrink-wrapping improvement

Thu Oct 22 13:01:07 PDT 2020

I am investigating whether .eh_frame on ELF platforms can be
compressed and I just come across this thread:)

The 2018 thread "Improving compact x86-64 compact unwind descriptors"
[0] discussed compact unwinding in depth. If we use multiple compact
unwind descriptors for one function (not implemented in LLVM
lib/Target/*/MCTargetDesc/*AsmBackend.cpp
generateCompactUnwindEncoding), we can cover prologues and epilogues.
( If prologues and epilogues are not covered, it is an issue that a
profiler cannot work on these areas.) However the discussed scheme
does not seem to be contributed into LLVM.
UNWIND_IS_NOT_FUNCTION_START is unimplemented as well (it is needed
for call-site table offsets in the LSDA)

CCing folks in that thread. The PDF from OpenVMS is still available
and is a very good read. (It'd be nice if it can include some code
examples, especially for the "null frame function" concept.)

[0]: http://lists.llvm.org/pipermail/llvm-dev/2018-January/120744.html
https://groups.google.com/g/llvm-dev/c/iCZaoe-OEHE/m/J6G7ObOKBAAJ

On Sat, May 16, 2020 at 9:38 AM Jimmy Zhongduo Lin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi Francis,
>
> Thank you for sharing your experience and insight.
>
> Thanks,
> Jimmy
>
> -----Original Message-----
> From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com]
> Sent: Friday, May 15, 2020 10:18 PM
> To: Jimmy Zhongduo Lin <jimmy.zhongduo.lin at huawei.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] RFC] Shrink-wrapping improvement
>
>
>
> > On May 15, 2020, at 7:02 AM, Jimmy Zhongduo Lin <jimmy.zhongduo.lin at huawei.com> wrote:
> >
> > Hi Francis,
> >
> > Thanks for getting back to me. Could you please provide more details
> > about the problems you encounter with those tools and what improvements required to improve compact unwinding format?
>
> In general, these tools expect a prologue and an epilogue, and sometimes can’t afford to read DWARF CFI for performance/memory reasons. Compact unwind has been created to efficiently describe how to unwind at any call site in the function. If we decide to shrink-wrap more, we can’t use a per-function compact unwind entry anymore, and we might need to revisit the format to handle these cases without having regressions in cases where we don’t shrink-wrap. While compact unwinding handles the case where we want to unwind through calls (also called synchronous) which is enough to satisfy exception handling, other tools like debuggers and profilers might need to know how to unwind at any instruction. The usual solution for these tools is to disassemble the function and try to understand how to unwind from any point in time. One example is LLDB which has a pretty nice “instruction emulator” that builds unwind plans based on instructions in the function, but other tools rely on a much simpler technique: walking the chain of frame pointers.
>
> > Most of my experience is in the mid end, but it is still surprising to me that an improved shrink wrap will break that many tools, considering the fact that gcc has a good shrink wrapping pass and shrink-wrap-separate pass.
>
> Sorry if that was confusing, I am talking about issues on Darwin platforms here (since these are the platforms that I’m interested in improving), which are the reasons why I am not actively working on this. I haven’t been following what was going on on other platforms, but I believe on Linux DWARF CFI is used most of the time which solves all these problems.
>
> >
> > Also, if possible, would you be able to share some performance numbers you get back then by improving shrink-wrap?
>
> The last numbers I have are the ones mentioned before in the RFC: https://lists.llvm.org/pipermail/llvm-dev/2017-August/116131.html.
>
> Thanks,
>
> — Francis
>
> >
> > Thanks,
> > Jimmy
> >
> > -----Original Message-----
> > From: Francis Visoiu Mistrih [mailto:francisvm at yahoo.com]
> > Sent: Thursday, May 14, 2020 7:30 PM
> > To: Jimmy Zhongduo Lin <jimmy.zhongduo.lin at huawei.com>
> > Cc: llvm-dev at lists.llvm.org
> > Subject: Re: [llvm-dev] RFC] Shrink-wrapping improvement
> >
> > Hi Jimmy,
> >
> >> On May 13, 2020, at 2:25 PM, Jimmy Zhongduo Lin via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> Sorry for bringing back such an old thread. I am interested in the latest status of the shrink wrapping pass in LLVM. I have found some active work back in 2017 from Francis Visoiu Mistrih and Kit Barton from the following links. However, it seems that all the work suddenly stops and the improvement for the existing shrink wrapping did not make it into the trunk. Is this work abandoned?
> >
> > Thanks for bringing this back.
> >
> > On my side, the last time I was working on this was more on the integration on the Darwin platforms. Most of these improvements break a lot of assumptions that lots of tools use (debuggers, profilers, crash reporters, unwinders, etc.). At least for Darwin, the gains we can get from such tools is a lot higher than the performance we get from improving shrink-wrapping. So first, we would need to come up with a solution to support such code out there (for example, improving the compact unwinding format), and then we can put more work into extending shrink-wrapping.
> >
> > Having said that, I can probably help with discussions and reviewing patches!
> >
> > Hope that helps,
> >
> > —
> > Francis
> >
> >>
> >> https://lists.llvm.org/pipermail/llvm-dev/2017-August/116131.html
> >> http://lists.llvm.org/pipermail/llvm-dev/2017-May/112687.html
> >> https://reviews.llvm.org/D41765
> >>
> >> Thanks,
> >> Jimmy
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
宋方睿