The new C backend has been pushed to the repository and it seems to work without a hitch. No particular effort has been directed at making it efficient (and none will since this backend is only a temporary measure). Initial testing shows it to be around 40-50 times faster than the interpreter.
Writing this backend was surprisingly easy; low-level Grin (LHC's intermediate language) can be directly pretty-printing as C code. By far the hardest part was giving up on LLVM and settling for C.
Future development will focus on grin-to-grin optimizations and a native code generator.
What problems did you encounter with LLVM that made you drop (or delay) it as a code generator?
ReplyDelete(1) Could not find a specification for the LLVM IR.
ReplyDelete(2) The type-system got in the way too often. (I'm saying this as a bondage-and-discipline loving Haskeller).
(3) The language has quite a few oddities I couldn't wrap my head around. For example, 'ret X' and '%local_var = X \n ret %local_var' are not the same.
Re 1: http://llvm.org/docs/LangRef.html is what I use when coding in IR. Or do you want a more formal spec?
ReplyDeleteRe 2: Yes, but in my experience static typing helped to catch A LOT of bugs.
Re 3: care to elaborate? Do you mean that you can't do 'ret add %1, 2'? This isn't possible in assembly either.
> Writing this backend was surprisingly easy
Hearing this makes me want to try coding a LLVM backend myself. Would you accept such a backend into LHC if I wrote it?
23Skidoo:
ReplyDeleteRe Re 1: Yes, the reference manual was helpful but a formal specification is essential.
Re Re 3:
This is valid:
ret i32 0
But this isn't:
%local_var = i32 0
ret i32 %local_var
This is valid though:
%local_var = bitcast i32 0 to i32
ret i32 %local_var
There may be a perfectly reasonable explanation for this but without a specification you wouldn't know.
Re LLVM backend:
Oh yes, absolutely. Contact me on email or irc and I'll help you in any way I can.