[llvm-dev] RFC: Removing TerminatorInst, simplifying calls

[Chris Lattner via llvm-dev]

> On May 17, 2018, at 2:03 AM, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Going to keep this RFC short and to the point:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> Then I propose we restructure the type system to allow CallInst and InvokeInst to easily share logic:
> - Create `CallBase` which is an *abstract* class derived from Instruction that provides all of the common call logic
> - Make `CallInst` derive from this
> - Make `InvokeInst` derive from this, extend it for EH aspects and successors
> - Remove `CallSite` and all accompanying code, rewriting it to use `CallBase`.
> 
> 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”.

+1, this seems like a great direction.  Random question, which we might have talked about but I forgot: can we just eliminate CallBase and InvokeInst entirely?  Why not make “isTerminator()” for calls return true if the call has a normal/unwind destination set?

-Chris