New version of LLVM backend, request to include in GHC head
marlowsd at gmail.com
Tue Jun 15 06:00:09 EDT 2010
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:
> 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:
> - Mutli commit patch:
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:
+outputLlvm dflags filenm flat_absC
+ = do ncg_uniqs <- mkSplitUniqSupply 'n'
+ doOutput filenm $ \f ->
+ LlvmCodeGen.llvmCodeGen dflags f ncg_uniqs flat_absC
+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")
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
hunk ./compiler/ghc.cabal.in 466
I wonder if this will still work when the NCG is disabled. Did you try?
> 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.
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc