[llvm-dev] [RFC] Machine Function Splitter - Split out cold blocks from machine functions using profile data

Modi Mo via llvm-dev llvm-dev at lists.llvm.org
Mon Aug 10 18:09:07 PDT 2020

On 8/10/20, 4:51 PM, "Snehasish Kumar" <snehasishk at google.com<mailto:snehasishk at google.com>> wrote:

+Rahman Lavaee<mailto:rahmanl at google.com> who is working on exception support for basicblock sections.

On Mon, Aug 10, 2020 at 4:29 PM Modi Mo <modimo at fb.com<mailto:modimo at fb.com>> wrote:


>All eh pads are grouped together regardless of their coldness and are part of the original function. There are outstanding issues with splitting eh pads if they reside in separate sections in the binary. This remains as part of future work.

Can you elaborate more on the outstanding issues with splitting eh pads?

From my dip into the unwind map in gcc_except_table the current encoding to landing pads using function-start relative offsets doesn’t extend well to moving the pads somewhere else. Are there additional issues with splitting specific pads out?
That's correct, we have a pending patch to add support for this. https://reviews.llvm.org/D73739<https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D73739&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=HlATw2CSJtDwZKMxZp741A&m=fw0QGLuBqIldiyAqSFQHTqUf-RDXmlvm6SYWv4mUcNw&s=VlUYBt2UBSgb_lYyLthx8VN8GoakTTtAc9wJhUIqwMs&e=>
IIUC with this patch, we can treat a set of ehpads as hot or cold and move them around as needed.



Thanks for the link!

Looks like the flexibility to define landing pad start (LPStart) is already built into the EH metadata format. Taking advantage of that should allow ehpads to go anywhere they please.

I’m looking at the runtime support and while gxx_personality_v0 (The C++ handler) does read LPStart gcc_personality_v0 (The C handler) purposefully ignores it. Pads in C can be generated due to “__attribute__((cleanup(func)))”. If C code is a candidate for these transforms this probably needs to be fixed up.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200811/d5b6a12f/attachment.html>

More information about the llvm-dev mailing list