[llvm-dev] RFC] Shrink-wrapping improvement

Sat May 16 09:37:41 PDT 2020

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
> 