Put the archive file in (on my computer) /home/alp/haskell/. Uncompress it with for example:

$ tar xzf ghc-HEAD-2009-10-23-ghc-corelibs-testsuite.tar.gz

You should get a /home/alp/haskell/ghc/ directory. Now we have to fetch the latest patches applied to GHC since the archive you downloaded got published on darcs.haskell.org. To do this, simply do:

$ chmod +x ./darcs-all
$ ./darcs-all pull -a

(the former may not be necessary though)
It can take some time, there may be a lot of patches to fetch and apply, don’t worry.

If you are not interested in having the LLVM backend, you can stop reading that section and go straight to the next one.

Once done with that, you have to download the patch to add the support to the LLVM backend to GHC. Just download the following file : http://www.cse.unséw.edu.au/~davidt/downloads/ghc-llvmbackend-full.gz (it actually just is a darcs patch, not an archive or anything else — you may want to rename it with a .patch extension), put it in ghc’s directory (/home/alp/haskell/ghc/ here) and apply the patch :

$ darcs apply ghc-llvmbackend-full.patch

(or .gz)

You just have one more patch to apply (isn’t life about applying patches?), written by Don Stewart, to be able to pass LLVM options to GHC without conflicting with other options. You can get it at http://www.galois.com/~dons/add-new-llvm-code-generator-to-ghc_.dpatch. Just move it to your ghc directory and darcs apply it, like you just did for the previous patch. (note: this step might not be necessary if the previous patch or the ghc repository contain it)

Ok, we are almost done! Now create a file named “build.mk” in (on my computer) /home/alp/haskell/ghc/mk/, and put the following content in that file:

GhcWithLlvmCodeGen = YES
GhcEnableTablesNextToCode = NO

The first, obviously, enables LLVM code generation in GHC. The second disables a feature currently being in conflict between the LLVM and the C code generators, if I remember correctly. Now, let’s build GHC, hooray!

Building and using the patched GHC non-intrusively

Once all the patches are fetched and applied, you just have to do:

$ sh boot
$ ./configure
$ make

Now, have a cup of coffee, read newspapers, try to solve P vs NP, whatever. It takes some time.

Once done with ‘make’, there should be many binaries in (on my computer) /home/alp/haskell/ghc/inplace/bin/. The ghc binary is called ghc-stage2

To check that the LLVM backend is enabled, as explained on Don’s post, just do the following (in the your ghc/inplace/bin/ directory):

$ ghc-stage2 –info

and verify that it gives you (“Have llvm code generator”,”YES”).

To make use of them properly without installing your brand new GHC HEAD system-wide, here is one possibility; add the following to your ~/.bashrc (or whatever you use, it’s just about defining variables):

But be careful, -fvia-C and -fllvm aren’t much friends, you may sometimes have to either edit the .cabal file of the package you want to install and removing -fvia-C from there, or via the –flags option of cabal install. For more informations, cabal help install.

Nice script indeed. The only missing thing would be to handle as automatically as possible the case of libraries containing an explicit -fvia-C flag, for example, like it’s been the case for uvector for me.

By the way, I had a *very* significant performance improvement with the LLVM backend, on the sample given with HNN. I took around 270-280 ms for the native and C code generator (6.12.1), and only around 90 ms with the LLVM backend (with GHC HEAD) ! The first version of HNN is uvector based.

EDIT : few hours after I published this post, I have seen the llvm patch (making LLVM understand GHC’s calling conventions for better performances) has been pushed upstream ! [see here]

The link works. Some browsers (chrome e.g) seem to be confused by the actual format of the file. The file is a plain darcs patch but the .gz extension may confuse the browser. Just download it (via right click > save as or simply wget) and call darcs apply on it while in ghc’s main directory.

I thought this looked interesting and tried out the steps. I updated GHC-head to the most recent revision, but then it doesn’t compile (I think something Simon Marlow is working on). I reverted a few of his most recent patches patches and now GHC compiles.

However, in this shape the binaries produced by the LLVM backend just seg-fault. Is there a particular `good’ revision of GHC that these patches can be applied to and have usable generated binaries?

Ah, I realized my problem: llvm now has the correct changes in the trunk, so I skipped the patching step for llvm. What I had to do to make it work was patch one of the GHC generated files to use the new calling convention that was just added to llvm.

I believe David had patched the “fastcc” calling convention directly in LLVM. However, now his patched fastcc is a separate calling convention now in LLVM-svn, `cc 10”. The above diff simply replaces how he prints his CC_Fastcc with the new calling convention (cc 10).

Ok, my bad: I downloaded different tarball previously and I thought that the one mentioned in the post is the same. After downloading GHC, I unpacked it, patched (with both patches to GHC) and edited Types.hs: