<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, May 17, 2018 at 9:27 AM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>+1, sounds like a great idea</p>
    <p>And if you're volunteering to do the work, even better! :)<br>
    </p>
    <p>Philip</p>
    <p>p.s. Any reason we can't preserve a TerminatorInst type with an
      isa function which just returns true for all our terminators but
      without having terminators actually inherit from it?  If so, we
      preserve the bit of a "type safety" for a variable which is
      expected to always point to a terminator.  <br></p></div></blockquote><div>Because it gives you UB instead of type safety?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>
    </p></div><div text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="m_615394171359356091moz-cite-prefix">On 05/17/2018 02:03 AM, Chandler
      Carruth via llvm-dev wrote:<br>
    </div>
    </div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite">
      <div dir="ltr">Going to keep this RFC short and to the point:
        <div><br>
        </div>
        <div>TerminatorInst doesn't pull its weight in the type system.
          There is essentially a single relevant API -- iterating
          successors. There is no other interesting aspect shared -- the
          interface itself just dispatches to specific instructions to
          be implemented.</div>
        <div><br>
        </div>
        <div>On the flip side, CallInst and InvokeInst have *massive*
          amounts of code shared and struggle to be effective due to
          being unable to share a base class in the type system. We have
          CallSite and a host of other complexity trying to cope with
          this, and honestly, it isn't doing such a great job.</div>
        <div><br>
        </div>
        <div>I propose we make "terminator-ness" a *property* of an
          instruction and take it out of the type system. We can build a
          handful of APIs to dispatch between instructions with this
          property and expose successors. This should be really
          comparable to the existing code and have nearly no down sides.</div>
        <div><br>
        </div>
        <div>Then I propose we restructure the type system to allow
          CallInst and InvokeInst to easily share logic:</div>
        <div>- Create `CallBase` which is an *abstract* class derived
          from Instruction that provides all of the common call logic</div>
        <div>- Make `CallInst` derive from this</div>
        <div>- Make `InvokeInst` derive from this, extend it for EH
          aspects and successors</div>
        <div>- Remove `CallSite` and all accompanying code, rewriting it
          to use `CallBase`.</div>
        <div><br>
        </div>
        <div>The end result will, IMO, be a much simpler IR type system
          and implementation. The code interacting with instructions
          should also be much more consistent and clear w/o the awkward
          CallSite "abstraction".</div>
        <div><br>
        </div>
        <div>Thoughts? Seem OK at a high level?</div>
        <div><br>
        </div>
        <div>Happy to bikeshed the name `CallBase`, but I've discussed
          this with several folks, including Reid and Chris and nothing
          better came up really. `CallSite` might be nicer, but the
          confusion with the *existing* type seems much more
          problematic.</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Assuming folks are happy with this direction, are there any
          incremental patches that folks would like to see in pre-commit
          review? I've only done some initial investigation of what it
          takes to cut this through. Provided folks are positive about
          the direction, I'll work on what this would actually look like
          in practice.</div>
        <div><br>
        </div>
        <div>-Chandler</div>
      </div>
      <br>
      <fieldset class="m_615394171359356091mimeAttachmentHeader"></fieldset>
      <br>
      </blockquote></div><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><pre>_______________________________________________
LLVM Developers mailing list
<a class="m_615394171359356091moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_615394171359356091moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote></div></blockquote></div></div>