[LLVMdev] Any optimization advantage to making a type-accurate vtable?
Talin
viridia at gmail.com
Sun Apr 13 16:42:20 PDT 2008
Here's another odd question I've been wondering about:
Typically a class vtable is an represented as an array of function
pointers. Now, since the functions all have different calling
signatures, I imagine that you would generate an array of opaque
pointers, and then bitcast the pointer to the actual function signature
at the call site.
However, that's not what I am doing. Instead, I decided to make the
vtable a struct rather than an array, and make each struct member be a
function pointer of the correct type. Since the syntax of getElementPtr
is the same whether the target is an array or struct, the generated IR
code looks much the same. The only difference is that you might have to
bitcast the vtable pointer itself if the true class is a subclass of the
reference type.
What I am wondering is if there is any optimization advantage to doing
this. In general I make it a policy to give the backend as much type
information as possible. However, in this case I wonder whether or not
there is any benefit - it seems to me that from the point of view of an
optimizer trying to determine what assumptions it can make about the
type of the callable, that bitcasting the vtable pointer and bitcasting
the vtable entry are pretty much equivalent.
-- Talin
More information about the llvm-dev
mailing list