patch: construct IntrinsicInst hierarchy directly

Benjamin Kramer benny.kra at gmail.com
Wed Feb 19 01:10:13 PST 2014



> Am 19 Feb 2014 um 06:27 schrieb Nick Lewycky <nlewycky at google.com>:
> 
> 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.

Getting rid of Value's vtable would be nice, it's a long standing issue.

http://llvm.org/bugs/show_bug.cgi?id=889

- Ben

> 
> Nick
> 
> <intrinsic-inst-ctor-1.patch>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list