[LLVMdev] Tool for run-time code generation?

[Nick Lewycky]

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
> child?

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 
information.

Nick