llvm dev - Apr 2008 - [LLVMdev] Any optimization advantage to making a type-accurate vtable?

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