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