How to add an include file

I’m writing a code transformation that involves adding an include to existing code, adding a base class
to and existing class and then linking with a previously compiled library. The main problem for me
seems to be how can I add the include? Can I compile the include alone to byte code and pre-pend it?
Should I compile the library, which includes the include and parse out the include and pre-pend it?
Am I missing something fundamental here?


If you want to add additional bitcode to an existing bitcode file, you
can link them together with llvm-link (or the equivalent C++ API
calls). Beyond that, I'm not following what you're trying to do.


Hi Eli,
Let’s say I have a file ClassA.h, that pairs with a file ClassA.cpp
to product a library libClassA.a.
ClassA.h contains the single declaration.

class A {…};

I want to transform it to:

#include “ClassB.h”

class A : public class B {…};

ClassB.h is the header file for a library libClassB.a built from ClassB.cpp and ClassB.h.
I can clearly link libClassB with libClassA. But how can I bring in the header file so that it’s declarations will be known in ClassA.h. Remember this is happening during a pass.


You have to rebuild libClassA.a from scratch; the generation of
bitcode makes too many hard-coded assumptions about the layout of
classes to manipulate the bitcode accurately.


I see,
Adding includes is trivial even w/o llvm, but the real problem here is manipulation of classes, if I understand you correctly adding an inheritee wouldn’t be possible.

The problem is that LLVM bitcode is not the right level of abstraction to approach this from. LLVM bitcode doesn't know anything about classes; classes are a higher-level language construct, and it's a front-end's responsibility to turn them into the lower-level types (with lower-level operations on them) that LLVM understands. Once you've built an LLVM type, it's immutable, so your "leaf class A" type would be different from your "class A with base B" type; you can't just modify the type in place, and as Eli said, LLVM instructions aren't designed for that anyway. And even if you cloned huge swathes of code, painstakingly replacing one type with the other and carefully updating member accesses, there's really no reason to think in general that the semantics of the result would match what you'd have gotten from declaring the proper class inheritance to begin with.

It sounds like what you really want is to hack a C++ front-end (like llvm-g++ or clang) to adjust its internal representation of class A before it's all lowered into bitcode. Is there a reason this needs to be done as part of some later optimization pass?