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

[Chris Lattner via llvm-dev]

> On May 18, 2018, at 10:28 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> 
> > 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.

I agree that this isn’t the right first step, just wondering about the end game on this.  It seems reasonable to go this way (depending on how “indirect branches” and up going) because various aspects of a call (including its operand count) are fixed at creation time.  “terminator or not” seems like something that would/should similarly be fixed at construction time.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180518/2f4206d9/attachment.html>