[LLVMdev] C++ type erasure in llvm-g++

Mike Stump mrs at apple.com
Tue Mar 24 10:08:16 PDT 2009


On Mar 24, 2009, at 8:40 AM, Luke Dalessandro wrote:
> Can someone more familiar with the llvm-gcc infrastructure comment on
> the difficulty of generating more strongly typed virtual function  
> tables
> rather than just having them all be variable length arrays of pointers
> of unknown type and casting to the "known" type before the call?

The easiest way would be to handle this in the gcc/llvm interface  
layer.  The type of each slot can easily be figured out and the type  
of the vtable can be built up as a structure instead of an array.  I'd  
guess it shouldn't be more than 100 lines.  Harder to do would be to  
transform the virtual dispatch code.  It is exposed as just raw add/ 
subtract, fetch and then indirect call.  Seems like part of the  
solution may be to propagate the ALIAS_SET information from the type  
system down for llvm to reason with.  It should be more complete and  
accurate than the information llvm has, though, maybe only marginally  
so.  The saving grace would be the code is heavily stylized and you're  
getting it before the optimizer swizzles it on you.  Since all the  
math is with constants usually, you just need to recognize the style  
and the type during the call and the type at the other end, where the  
pointer arithmetic starts and the transform back into the usual llvm  
accessors for structures.  Annoying to do, but, probably under 200  
lines.

> Any other suggestions would be appreciated.

Sure, just add code to propagate the types around, add code to handle  
constant arithmetic on these things and and to handle normal virtual  
dispatches, after that, add support for pointer to member functions  
and you're done.  You should be able to figure out that these things  
don't escape much, that for a given constant (index), the same shape  
(type) is always used, that for a given variable (pointer to member  
function), that the same shape (type) is used and all assignments of  
this variable come from things of the same shape or that they comes  
from literals that have the same shape.



More information about the llvm-dev mailing list