patch: construct IntrinsicInst hierarchy directly

Nick Lewycky nlewycky at google.com
Tue Feb 18 21:27:55 PST 2014


LLVM's hand-rolled RTTI differs from C++'s in that it allows you to call
the construction method on a base class and then based on the dynamic
arguments decide to construct a more derived type and return a pointer to
that. This looks like calling CallInst::Create and getting back something
you can cast<MemSetInst>(). However, we implement this by new'ing a
CallInst, which breaks C++ aliasing rules.

The attached patch fixes this undefined behaviour by making CallInst
forward to IntrinsicInst to construct intrinsics, which in turn uses
private constructors on the most derived types. There is some runtime cost,
as the implementation of CallInst::Create moved from the header to the .cpp
file. If this is a serious problem, let me know and I can probably fix
that, I just think the result will result in less much readable code.

Please review!

As a related issue, I notice that Value has an unnecessary vtable. There's
no pressing need to get rid of either form of RTTI (nobody uses
dynamic_cast, just normal virtual dispatch), but I want to understand how
this happened and whether it's okay to use going forward, or if that
happened while nobody was looking and I should go hammer it out of there.
It looks like removing it will be a mechanical change.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140218/fa63ff0b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: intrinsic-inst-ctor-1.patch
Type: text/x-patch
Size: 28894 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140218/fa63ff0b/attachment.bin>


More information about the llvm-commits mailing list