[LLVMdev] Implementing devirtualization

David Blaikie dblaikie at gmail.com
Thu Dec 8 12:04:20 PST 2011


On Thu, Dec 8, 2011 at 9:56 AM, Vitor Luis Menezes <vitor at utexas.edu> wrote:
> Hello all,
>
> Our compilers class has been using LLVM, and a partner and I decided to
> implement devirtualization of virtual C++ calls in LLVM as a class project.
> We quickly realized that existing debug metadata generated by Clang didn't
> give us enough info to (precisely) implement this, and as such have already
> begun modifying Clang to insert such metadata. However, for devirtualization
> we also need to reconstruct the class hierarchy, which we also seek to do
> through metadata. There appears to be sufficient metadata to do this, but we
> can't seem to figure out how to actually access this metadata and
> successfully reconstruct the class hierarchy. Can anyone help with this?
>
> We're also open to alternative approaches, but we'd like to stay in LLVM IR
> as much as possible.

Some of this is already done by LLVM/Clang - do you have particular
cases that aren't being devirtualized that you want to focus on?

For some brief background reading you might want to take a look at these bugs:
http://llvm.org/bugs/show_bug.cgi?id=3100
http://llvm.org/bugs/show_bug.cgi?id=810

Which are things I (& others more experienced than myself) have posted
some thoughts on. If you're interested in pursuing PR810 then I have
some code that Nick Lewycky passed on to me involving his experiments
in this domain. & I'm also going to CC Eric Christopher because he
mentioned he'd had some thoughts on how to achieve this (the general
problem described in 810 about how to pass assumptions/facts from the
frontend to the backend) & I never got around to asking him about the
details.

This approach should stay even more in LLVM IR than your proposed
solution of metadata or debug info, but it may have
limitations/problems that your proposed approach does not - so I
certainly wouldn't rule anything out just yet.

- David



More information about the llvm-dev mailing list