[LLVMdev] Proposal for TableML, llvmc2 configuration language

[Mikhail Glushenkov]

Hi Patrick,

> I've been working on a proof of concept for a new configuration language 
> for LLVM: specifically for my needs in llvmc2, but I have tried to make 
> it as generic as possible for use throughout LLVM if other projects 
> would like to make use of it.

Your proposal seems interesting - I especially like that you are using a
functional language. When your compiler will be able to generate llvmc plugins,
it will provide a nice TableGen alternative for llvmc.

> val make32bit = (fn x => strcat("e", x))
> def val RegisterInfo = map make32bit [ "ax", "bx", "cx", "dx" ]

It'd probably be nice if it was possible to syntactically distinguish between
what is evaluated at run-time and at compile-time (like in Template Haskell).

> The subset of Standard ML that TableML supports is essentially
> the one shown here:
> http://www.macs.hw.ac.uk/ultra/compositional-analysis/
type-error-slicing/slicing.cgi

As I understand from this link, TableML supports only lists and some primitive
types (no algebraic datatypes).

That'd be enough for llvmc, but I can't speak for the other
backends; you'll probably need to integrate some additional
syntactic sugar to cater to their needs.

> This means that, unlike TableGen, 
> backends that want to allow scripting (which is currently just llvmc2) 
> don't have to define their own programming languages. Instead, they can 
> simply request a definition with a function type (e.g. SomeFunction : 
> int -> int). TableML will hand the AST for the function, as well as its 
> values, over to the backend for emission as C++ code.

Another (pie-in-the-sky) option is to compile TableML to LLVM IR and integrate
llvmc with the JIT engine.
That way llvmc won't even need a C++ compiler present to support plugins.
But that's probably too heavyweight for a humble compiler driver:)