Currently, Hot Cold Splitting does not support outlining exception handling regions.
The difficulties of outlining EH regions are as follows:
- We cannot extract the block containing the invoke, otherwise we'll potentially extract the hot branch as well;
- We cannot extract the entire landing pad block, since the first instruction after the unwind edge into the lpad block must be the landingpad instruction.
- It seems possible to simply split the lpad block into two from the first instruction, and then outling starting from there; this is analogous to issue #4, which we outline below;
- The block at catch.dispatch contains potentially a series of calls to the eh.typeid.for intrinsic to use function-specific type information to match if the catch call can go through. As such, CodeExtractor cannot extract these calls (See detailed discussion and example in https://bugs.llvm.org/show_bug.cgi?id=39545). Making typeid.for outlining-friendly seems in general a difficult task, as the proposed patch in 39545 uses an entirely new pass to do so.
What remains is the idea of extracting the typeid.for intrinsic calls to
further up in the control flow graph. Without calls to eh.typeid.for intrinsic,
we can perform outlining safely and store the resultant values in some variable.
To safely implement this strategy, we need to hoist these call instructions to
the highest post-landingpad block that dominates them. Otherwise, incorrect compilation
might happen with cases of nested try/catches.
Empirical evaluation with -Os on Firefox yields the following data:
-Os, EH outlining enabled: 142678 cold regions detected/62985 cold regions outlined, code size: 2.187481424GB -Os, EH outlining disabled: 142081 cold regions detected/62982 cold regions outlined, code size: 2.188262032 GB