RFC] Shrink-wrapping improvement

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?

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

Hi Jimmy,

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? 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.

Also, if possible, would you be able to share some performance numbers you get back then by improving shrink-wrap?

Thanks,
Jimmy

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

Hi Francis,

Thank you for sharing your experience and insight.

Thanks,
Jimmy

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