[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