LLVM back end

Simon Marlow simonmarhaskell at gmail.com
Tue Dec 19 08:13:27 EST 2006

Michael T. Richter wrote:
> I've been eyeing LLVM[1 <http://llvm.org>] as interesting technology -- 
> brief executive summary: a virtual machine suited as the back end of 
> compiler output with optimised native code then coming from it as either 
> JIT-based execution of the LLVM bytecode or as a further compilation 
> step -- and couldn't help but immediately think of the possibility of 
> one of the Haskell compiler projects providing an LLVM code generator.  
> I think this would help in several areas:
>     * it could make porting the compiler to other architectures --
>       including oddball ones that would be too small to otherwise
>       support -- easier;
>     * it could help remove the nigh-ubiquitous reliance upon GCC as a
>       back-end (while I think that GCC is a pretty good piece of
>       software, I'm not sure it's really suited to its current role as
>       the "do-everything" back end);
>     * it could leverage some of the really interesting work that's going
>       on in optimisation technology by letting one VM's optimiser do the
>       work for any number of languages;
>     * it could improve interaction between source code written in
>       multiple languages. 
> Is this me opening up a Pandora's Box of ignorance here?  Or is LLVM 
> potentially interesting?  (And were someone motivated into perhaps 
> trying to make an LLVM back-end, where would one start to poke around 
> in, say, the GHC codebase to even begin to implement this?  And how 
> insane would they be driven by the process?)

Apologies for the slow reply.  Actually I think this is a pretty cool idea (with 
a disclaimer that I know very nearly nothing about LLVM).  Provided there are no 
serious gotchas, what you need to do is write a new backend for GHC that 
translates Cmm to LLVM.  This should be pretty straightforward: for example, the 
Cmm->C code generator is only 1000 lines of Haskell:


I hope LLVM lets you put data next to code, which is what GHC needs for its info 
tables.  Also I hope it lets you fix global registers.


More information about the Glasgow-haskell-users mailing list