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

[Chandler Carruth via llvm-dev]

On Thu, May 17, 2018 at 6:23 AM Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Are there any instructions that aren't terminators now, but will become
> terminators with this change?


Nope.


>   I'm wondering if this is going to affect
> reading old bitcode, and if so, how it will be handled.
>

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


>
> -Krzysztof
>
> On 5/17/2018 4: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?
> >
> > 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.
> >
> >
> > 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
> >
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180517/fe92424b/attachment.html>