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

[Philip Reames via llvm-dev]

+1, sounds like a great idea

And if you're volunteering to do the work, even better! :)

Philip

p.s. Any reason we can't preserve a TerminatorInst type with an isa 
function which just returns true for all our terminators but without 
having terminators actually inherit from it?  If so, we preserve the bit 
of a "type safety" for a variable which is expected to always point to a 
terminator.


On 05/17/2018 02: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

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