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

[Hal Finkel via llvm-dev]

On 05/17/2018 04:03 AM, Chandler Carruth via llvm-dev 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".
>
> Thoughts? Seem OK at a high level?

I think this is a good idea.

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

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.

 -Hal

>
>
> 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.
>
> -Chandler
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180517/926bbb66/attachment.html>