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

[Chandler Carruth via llvm-dev]

On Fri, May 18, 2018 at 10:26 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

Eventually, this might make sense, but I'm not currently certain.

I think storing stuff like successors is useful to model as a separate type
to start. Once we get there, I think it'll be easier to see if the tradeoff
isn't actually worth it and we can just make this a a property of calls.


>
> -Chris
>
> _______________________________________________
> 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/20180518/9ee85d0e/attachment-0001.html>