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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
