On 15 June 2010 11:00, Simon Marlow <[email protected]> wrote:
> 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.

Sure. This can go away though since TNTC support has just been added :).

>
> +    -- 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?

Yeah it does, I have tested. It used to cause problems before I moved
that stgReg fixing up stuff into CgUtils, but now the only thing the
LLVM backend uses from the NCG source tree is the PprBase module which
doesn't depend on any other modules in the NCG. In fact the only thing
I use from the NCG is this function:

doubleToBytes :: Double -> [Int]
doubleToBytes d
   = runST (do
        arr <- newArray_ ((0::Int),7)
        writeArray arr 0 d
        arr <- castDoubleToWord8Array arr
        i0 <- readArray arr 0
        i1 <- readArray arr 1
        i2 <- readArray arr 2
        i3 <- readArray arr 3
        i4 <- readArray arr 4
        i5 <- readArray arr 5
        i6 <- readArray arr 6
        i7 <- readArray arr 7
        return (map fromIntegral [i0,i1,i2,i3,i4,i5,i6,i7])
     )

So its kind of tempting to once again move some of this code outside
of the NCG so that it can be easily used by LLVM and NCG without this
awkward cabal arrangement.

Cheers,
David

_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc

Reply via email to