<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 17, 2018, at 19:37, Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class=""><br class="">
</p>
<br class="">
<div class="moz-cite-prefix">On 05/17/2018 04:03 AM, Chandler
Carruth via llvm-dev wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAAwGriGHh=h2uQLCwjx2J=Z3JGB0YqqW4ZmcHyapTPw2L1MyLA@mail.gmail.com" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div dir="ltr" class="">Going to keep this RFC short and to the point:
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">Then I propose we restructure the type system to allow
CallInst and InvokeInst to easily share logic:</div>
<div class="">- Create `CallBase` which is an *abstract* class derived
from Instruction that provides all of the common call logic</div>
<div class="">- Make `CallInst` derive from this</div>
<div class="">- Make `InvokeInst` derive from this, extend it for EH
aspects and successors</div>
<div class="">- Remove `CallSite` and all accompanying code, rewriting it
to use `CallBase`.</div>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">Thoughts? Seem OK at a high level?</div>
</div>
</blockquote>
<br class="">
I think this is a good idea.<br class=""></div></div></blockquote><div><br class=""></div>+1</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite" cite="mid:CAAwGriGHh=h2uQLCwjx2J=Z3JGB0YqqW4ZmcHyapTPw2L1MyLA@mail.gmail.com" class="">
<div dir="ltr" class="">
<div class="">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>
</blockquote>
<br class="">
I think that we should take whatever name we like the best.
Out-of-tree code will fail to compile after the change either way
and will require fixing. That having been said, we already have a
CallBase (and a CallBaseParent), they're just not part of the
classof hierarchy, and using CallBase seems consistent with our
other class names.<br class=""></div></div></blockquote><div><br class=""></div><div>I agree that using CallBase makes sense here.</div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
<blockquote type="cite" cite="mid:CAAwGriGHh=h2uQLCwjx2J=Z3JGB0YqqW4ZmcHyapTPw2L1MyLA@mail.gmail.com" class="">
<div dir="ltr" class="">
<div class="">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 class=""><br class="">
</div>
<div class="">-Chandler</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br class="">
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>