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

[Wenlei He via llvm-dev]

Thanks for pointer to 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=>. Large part of that patch of involves coping with the dis-contiguity resulted from BB section, so EH table need to be broken up. If we want EH pad splitting to work with regular function (without BB section), it looks to me that the flexibility from explicit LPStart, plus the change to deal with zero offset landing pad should be enough?

We’re looking into separating out EH pads too as Modi pointed out, even without profile data.

Thanks,
Wenlei

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Modi Mo via llvm-dev <llvm-dev at lists.llvm.org>
Reply-To: Modi Mo <modimo at fb.com>
Date: Monday, August 10, 2020 at 6:09 PM
To: Snehasish Kumar <snehasishk at google.com>, Rahman Lavaee <rahmanl at google.com>
Cc: aditya kumar <hiraditya at gmail.com>, llvm-dev <llvm-dev at lists.llvm.org>, David Li <davidxl at google.com>, "efriedma at codeaurora.org" <efriedma at codeaurora.org>
Subject: Re: [llvm-dev] [RFC] Machine Function Splitter - Split out cold blocks from machine functions using profile data

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:

>Exceptions

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



Best,

Modi


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/5a134f67/attachment.html>