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

Dean Michael Berris via llvm-dev
Thu, 17 May 2018 16:47:25 -0000

> On 17 May 2018, at 19:03, 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.
>

I think I’m missing one key point here — there’s a number of types that derive
from TerminatorInst (http://llvm.org/doxygen/classllvm_1_1TerminatorInst.html)
and none of them seem like they’re related to calls. Most seem like branching
instructions and “unreachable”. Is the idea to lift the access to successors to
a separate set of functions, taking an instruction that’s a terminator somehow?
Will it be part of the Instruction base type or something else?

> 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".
>
> Thoughts? Seem OK at a high level?
>

IIUC, this is replacing what’s already there, which is a CallBase template
(doing CRTP I suppose) — with something that’s just an abstract base sharing
common code?  That does sound simpler, but it’d be nice to also understand what
removing the CallSite abstraction make easier (for my education).

> 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.
>

CallPoint? CallLocation? CallBase isn’t bad but it seems like it’s already
there...

>
> 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.
>

+1 from me.

-- Dean