Hi All,

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

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
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to