<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><span class="vcard"><a class="email" href="mailto:vsk@apple.com" title="Vedant Kumar <vsk@apple.com>"> <span class="fn">Vedant Kumar</span></a>
</span> changed
          <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED LATER - Make @llvm.eh.typeid.for outlining-friendly"
   href="https://bugs.llvm.org/show_bug.cgi?id=39545">bug 39545</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>LATER
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>NEW
           </td>
           <td>RESOLVED
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED LATER - Make @llvm.eh.typeid.for outlining-friendly"
   href="https://bugs.llvm.org/show_bug.cgi?id=39545#c14">Comment # 14</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED LATER - Make @llvm.eh.typeid.for outlining-friendly"
   href="https://bugs.llvm.org/show_bug.cgi?id=39545">bug 39545</a>
              from <span class="vcard"><a class="email" href="mailto:vsk@apple.com" title="Vedant Kumar <vsk@apple.com>"> <span class="fn">Vedant Kumar</span></a>
</span></b>
        <pre>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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>