[LLVMdev] Tool for run-time code generation?
nicholas at mxc.ca
Sat Jul 17 09:38:46 PDT 2010
Martin C. Martin wrote:
> On 7/16/2010 10:30 PM, Nick Lewycky wrote:
>> Vlad wrote:
>> Instead, break the chunks of C you would generate into functions and
>> compile those ahead-of-time. At run time you use llvm only (no clang) to
>> generate a series of function calls into those functions.
> Compelling. I hadn't considered that.
> In our application, we have a tree of primitive operations, where each
> one calls into its children and returns to its parent. There are various
> types of nodes, and we don't know the topology or types of nodes until
> runtime (i.e. Clang/LLVM invocation time). Each operation is pretty
> simple, so we'd like to inline the children's operations into the parent
> where a C compiler would do it.
> Could your technique be extended to that? e.g. precompile to LLVM IR
> with calls to a non-existent "node_do_foo()" call, and then replace it
> with the specific "childtype_do_foo()" call when we know the type of the
Will you know the prototype of the function call in advance? If so, you
can do something really simple where you write the C functions with a
function pointer parameter. Then at run-time, use
llvm::CloneAndPruneFunctionInto to produce the specialized function by
giving it a valuemap that maps the Argument* for the fptr to the
concrete Function* you want it to call.
If you don't know the type of the call you intend to place, the question
becomes "why not?" What arguments were you planning to pass it, if you
don't know how many arguments it takes in advance? I don't see any
reason to doubt that it's possible to do, but I would need more details
before I could suggest an implementation.
>> Since the
>> optimizers are all in LLVM proper, you should get the exact same
>> assembly out.
> This is something I've been wondering. Since Clang has different
> information than the LLVM IR, it seems there should be some
> optimizations that would be easy to do in Clang, but
> difficult/impossible to do in LLVM. No? Not even for C++?
Yes. Copy constructor elimination is permitted by C++ even though it may
change the visible behaviour of the program. I think NRVO is also done
in the frontend.
The sterling example is type-based alias analysis (which most people
know of as -fstrict-aliasing in GCC). C++ has rules which state that
sometimes pointers can't alias depending on their types. The LLVM type
system is not the C++ type system so we can't just apply those rules,
and Clang doesn't have the sort of low-level optimizations that would
benefit from this information. The eventual plan is to make clang tag
loads and stores with metadata indicating what 'aliasing group' they
belong to, then provide an alias analysis pass in LLVM which uses that
More information about the llvm-dev