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

Chris Lattner via llvm-dev
Sat, 19 May 2018 05:26:04 -0000

> 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