[LLVMdev] IR function pointers

[apala guha]

Hi Tim,

This is C++ indeed. Basically, I am profiling the code. So, these edges 
that cannot be resolved at compile time present a problem.

Where can I find these devirtualization optimizations that you mentioned?

Thanks.
-Apala

On 01/01/2013 12:18 PM, Tim Northover wrote:
>
> Hi,
>
> > For example: call void %1608(%"struct.LRT::RGBAucharFrameBuffer"*
> > %1604)
> >
> > How can I resolve the targets of these? Also, why are they appearing as
> > indirect calls in the IR, when they are direct calls in the source?
>
> You don't mention what language you're trying to compile, though it 
> looks plausibly C++. I'd guess these are virtual function calls. In 
> general you can't tell which actual function will be called at 
> compile-time, since it will depend on the precise class of the object 
> being used.
>
> LLVM can unpick some of this (the optimistions go under the generic 
> term of "devirtualisation"), but obviously not all.
>
> If you as a reader just want to know what function's being called in 
> broad terms, I'd look at where that %1608 comes from: likely loaded 
> from an offset in the vtable, stored in %1604. Very roughly for Unixy 
> ABIs (and loosely typed):
>
> %vtable = load i8** %1604
> %fptr = getelementptr %vtable, NNN
> %1608 = load %fptr
>
> Work out where that NNN offset actually is and then look at 
> RGBAucharFrameBuffer's vtable *definition* (the global symbol 
> @_ZTV3LRT20RGBAucharFrameBuffer, I believe: the _ZTV is the important 
> bit) and see which function is put in that offset. Unfortunately, it's 
> all rather complicated and the vtable may not even be defined in the 
> file you're compiling.
>
> Why are these calls bothering you? It's possible there are better 
> options for your use-case.
>
> Tim.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130101/f6f8b813/attachment.html>