[llvm-bugs] [Bug 39545] Make @llvm.eh.typeid.for outlining-friendly

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39545

Vedant Kumar <vsk at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |LATER
             Status|NEW                         |RESOLVED

--- Comment #14 from Vedant Kumar <vsk at apple.com> ---
I prototyped a ModulePass which lifts EH type tables into IR, and taught
CodeExtractor how to insert intrinsics into extracted functions s.t type tables
are shared.

The idea is basically what Heejin described in llvm.org/PR39917, and what John
alluded to here: 1) declare the EH type tables in IR, and 2) introduce an
intrinsic which allows functions to share type tables. A module pass is needed
to identify connected components of functions which all must share the same
type tables.

I'll attach the patches here for posterity. Ultimately, what I found is that
this does not substantially improve the efficacy of hot/cold splitting. On our
stack, it's possible to achieve 98% of the results without actually splitting
out landingpads / eh_typeid_for. What's more, the code size growth imposed by
shared type tables is greater than the cost of simply treating eh_typeid_for as
an input to the extraction region.

In light of this data, I think 'later' is a reasonable resolution for this bug:
we can resurrect this idea if extracting landingpads at the IR-level becomes
important down the road.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190117/4d2a4b94/attachment.html>