Alex Ford | 29 Jun 02:41 2013
Picon

Improving GHC's LLVM Backend

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:

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/LLVM contains 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 <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Erik de Castro Lopo | 29 Jun 06:05 2013

Re: Improving GHC's LLVM Backend

Alex,

I really suggest you take this to the ghc-devs mailing list.

Cheers,
Erik

Alex Ford wrote:

> 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

--

-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Gmane