[Haskell-cafe] Improving GHC's LLVM Backend

[Alex Ford]

Hello,

I'm interested in improving the LLVM backend of GHC by using the existing
Haskell LLVM bindings to the C API, as suggested by option 1 in the LLVM
FAQ:
http://llvm.org/docs/FAQ.html#i-d-like-to-write-a-self-hosting-llvm-compiler-how-should-i-interface-with-the-llvm-middle-end-optimizers-and-back-end-code-generators

At the moment, the backend uses the option 2: emitting LLVM assembly code
which is then assembled to LLVM bitcode, optimised, and compiled to machine
code by standard LLVM tools. Changing this to use the Haskell FFI bindings
to the LLVM C API would allow better tracking of any changes to the LLVM
IR, and hopefully a reasonable speed increase by avoiding the overhead of
first emitting LLVM Assembly to be assembled.


In his bachelor's thesis, David Terei considered this approach when
initially writing the LLVM backend, but dismissed it due to the existing
Haskell bindings being too large and high level to use with GHC. I have not
personally looked at the high level Haskell bindings in much depth, but the
low level (llvm-base) bindings appear to be somewhat incomplete with
respect to LLVM 3.3. Therefore, I plan to extend the FFI bindings to cover
more or all of the C API, and then to modify the GHC LLVM backend to use
these bindings to call into the LLVM libraries directly.

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVMcontains
a link to David's thesis, as well as documentation of the LLVM
backend.

I'd really appreciate it if anyone who knows about the Haskell LLVM
bindings or about the GHC LLVM backend could give any advice regarding what
sort of work needs to be done with the LLVM bindings to make them more
appropriate for use within GHC, or how to approach modifying the existing
LLVM backend.

Many thanks,
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130629/43308b59/attachment.htm>