<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, May 17, 2018 at 6:23 AM Krzysztof Parzyszek via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are there any instructions that aren't terminators now, but will become <br>
terminators with this change?</blockquote><div><br></div><div>Nope.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  I'm wondering if this is going to affect <br>
reading old bitcode, and if so, how it will be handled.<br></blockquote><div><br></div><div>Shouldn't change anything. Just changes the in-memory representation. We'll still create the instructions the same way and so bitcode should Just Work. (but clearly something to test and verify.)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Krzysztof<br>
<br>
On 5/17/2018 4:03 AM, Chandler Carruth via llvm-dev wrote:<br>
> Going to keep this RFC short and to the point:<br>
> <br>
> TerminatorInst doesn't pull its weight in the type system. There is <br>
> essentially a single relevant API -- iterating successors. There is no <br>
> other interesting aspect shared -- the interface itself just dispatches <br>
> to specific instructions to be implemented.<br>
> <br>
> On the flip side, CallInst and InvokeInst have *massive* amounts of code <br>
> shared and struggle to be effective due to being unable to share a base <br>
> class in the type system. We have CallSite and a host of other <br>
> complexity trying to cope with this, and honestly, it isn't doing such a <br>
> great job.<br>
> <br>
> I propose we make "terminator-ness" a *property* of an instruction and <br>
> take it out of the type system. We can build a handful of APIs to <br>
> dispatch between instructions with this property and expose successors. <br>
> This should be really comparable to the existing code and have nearly no <br>
> down sides.<br>
> <br>
> Then I propose we restructure the type system to allow CallInst and <br>
> InvokeInst to easily share logic:<br>
> - Create `CallBase` which is an *abstract* class derived from <br>
> Instruction that provides all of the common call logic<br>
> - Make `CallInst` derive from this<br>
> - Make `InvokeInst` derive from this, extend it for EH aspects and <br>
> successors<br>
> - Remove `CallSite` and all accompanying code, rewriting it to use <br>
> `CallBase`.<br>
> <br>
> The end result will, IMO, be a much simpler IR type system and <br>
> implementation. The code interacting with instructions should also be <br>
> much more consistent and clear w/o the awkward CallSite "abstraction".<br>
> <br>
> Thoughts? Seem OK at a high level?<br>
> <br>
> Happy to bikeshed the name `CallBase`, but I've discussed this with <br>
> several folks, including Reid and Chris and nothing better came up <br>
> really. `CallSite` might be nicer, but the confusion with the *existing* <br>
> type seems much more problematic.<br>
> <br>
> <br>
> Assuming folks are happy with this direction, are there any incremental <br>
> patches that folks would like to see in pre-commit review? I've only <br>
> done some initial investigation of what it takes to cut this through. <br>
> Provided folks are positive about the direction, I'll work on what this <br>
> would actually look like in practice.<br>
> <br>
> -Chandler<br>
> <br>
> <br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
<br>
-- <br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, <br>
hosted by The Linux Foundation<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>