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

[Chandler Carruth via llvm-dev]

On Thu, May 17, 2018 at 9:27 AM Philip Reames <listmail at philipreames.com>
wrote:

> +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.
>
Because it gives you UB instead of type safety?


>
> 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 listllvm-dev at lists.llvm.orghttp://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/f0d1a28d/attachment.html>