New version of LLVM backend, request to include in GHC head

[Simon Marlow]

On 09/06/2010 19:17, David Terei wrote:

> I've got around to producing a new version of the llvm backend for
> GHC. It fixes most of the issues in the first patch that people had.
> For more information about the backend visit its webpage here:
>
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM
>
> I've created two versions of the patch, one which is a single darcs
> commit and a second one which includes the full history of changes
> since the first version of the patch. First patch is what I think should be
> included in GHC but second patch may help in people reviewing it or
> updating current builds they have:
>
>   - Single commit patch:
> http://www.cse.unsw.edu.au/~davidt/downloads/ghc-llvmbackend-onepatch.dpatch
>   - Mutli commit patch:
> http://www.cse.unsw.edu.au/~davidt/downloads/ghc-llvmbackend-full.dpatch

Great stuff... I'm validating the patch now, and if validate passes I'll 
push it.  I had to amend the patch because it conflicted with some 
whitespace changes that Ian had made, so you'll need to unpull your 
version before pulling from GHC HEAD.

Here are a couple of things we should look at when the patch is in:

+#ifndef GHCI_TABLES_NEXT_TO_CODE
+outputLlvm dflags filenm flat_absC
+  = do ncg_uniqs <- mkSplitUniqSupply 'n'
+       doOutput filenm $ \f ->
+	         LlvmCodeGen.llvmCodeGen dflags f ncg_uniqs flat_absC
+#else
+outputLlvm _ _ _
+  = pprPanic "This compiler was built with the LLVM backend disabled"
+	     (text ("This is because the TABLES_NEXT_TO_CODE optimisation is"
+         ++ " enabled, which the LLVM backend doesn't support right now.")
+         $+$ text "Use -fasm instead")
+#endif

use cGhcEnableTablesNextToCode rather than GHCI_TABLES_NEXT_TO_CODE. 
I'm not sure why we have the latter, actually.

+    -- We only need to expose more modules as some of the ncg code is used
+    -- by the LLVM backend so its always included
      if flag(ncg)
hunk ./compiler/ghc.cabal.in 466
-        hs-source-dirs:
-            nativeGen
-

I wonder if this will still work when the NCG is disabled.  Did you try?

Cheers,
	Simon





> Here are some specific responses to elements of the review for the
> previous patch:
>
>   >  [David Peixotto]: Nice if -ddump-llvm implies -fllvm
>
> I haven't made this change at the moment since the rest of GHC's dump
> flag don't work in this manner. If people would prefer the change its
> easy to make but consistency seemed more important.
>
> hunk ./compiler/ghc.cabal.in 44
> + Flag llvm
> +    Description: Build the LLVM code generator.
> +    Default: False
> +    Manual: True
>
>   >  [Simon Marlow]: CLEAN Is there a good reason to want to disable the
>   >  LLVM support, or can it always be compiled in?
>
> Yes, if TNTC is enabled then the backend doesn't work. However I've
> removed all this and always include the LLVM code. If TNTC is enabled
> though GHC will tell tell you that the LLVM backend can't be used when
> you try, instead of just failing like it used to.
>
> A large part f the issue with the original patch was also its use of
> slower data types like [], Map and String instead of OrdList, UniqFM
> and FastString. A lot of these have been fixed up but some ugly type
> changes remain where you get things like (CLabel ->  SDoc ->  Doc ->
> String ->  FastString ->  String ->  Doc). This is all because the LLVM
> binding uses Show for printing. I've left it unchanged for now as a
> Google Summer of Code student, Alp Mestanogullari, is working on
> replacing the current binding that prints LLVM assembly, with one that
> interfaces with the LLVM API/libraries.
>
> Cheers,
> David
>
> _______________________________________________
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
> http://www.haskell.org/mailman/listinfo/cvs-ghc