March 2013 - ghc-devs

Advance notice that I'd like to make Cabal depend on parsec
by Duncan Coutts 15 Mar '13

15 Mar '13

Hi folks, I want to give you advance notice that I would like to make Cabal depend on parsec. The implication is that GHC would therefore depend on parsec and thus it would become a core package, rather than just a HP package. So this would affect both GHC and the HP, though I hope not too much. The rationale is that Cabal needs to parse things, like .cabal files and currently we do not have a decent parser in the core libraries. By decent I mean one that can produce error messages with source locations and that doesn't have unpredictable memory use. The only parser in the core libraries at the moment is Text.ParserCombinators.ReadP from the base package and that fails my "decent" criteria on both counts. Its idea of an error message is (), and on some largish .cabal files we take 100s of MB to parse (I realise that the ReadP in the base package is a cutdown version so I don't mean to malign all ReadP-style libs out there). Partly due to the performance problem, the terrible .cabal file error messages, and partly because Doaitse Swierstra keeps asking me if .cabal files have a grammar, I've been writing a new .cabal parser. It uses an alex lexer and a parsec parser. It's fast and the error messages are pretty good. I have reverse engineered a grammar that closely matches the existing parser and .cabal files in the wild, though I'm not sure Doaitse will be satisfied with the approach I've taken to handling layout. Why did I choose parsec? Practicality dictates that I can only use things in the core libraries, and the nearest thing we have to that is the parser lib that is in the HP. I tried to use happy but I could not construct a grammar/lexer combo to handle the layout (also, happy is not exactly known for its great error messages). I've been doing regression testing against hackage and I'm satisfied that the new parser matches close enough. I've uncovered all kinds of horrors with .cabal files in the wild relying on quirks of the old parser. I've made adjustments for most of them but I will be breaking a half dozen old packages (most of those don't actually build correctly because though their syntax errors are not picked up by the parser, they do cause failure eventually). So far I've just done the outline parser, not the individual field parsers. I'll be doing those next and then integrate. So this change is still a bit of a ways off, but I thought it'd be useful to warn people now. Duncan

7 11

Re: Advance notice that I'd like to make Cabal depend on parsec
by Roman Cheplyaka 15 Mar '13

15 Mar '13

* Ivan Lazar Miljenovic <ivan.miljenovic(a)gmail.com> [2013-03-15 22:12:47+1100] > On 15 March 2013 22:05, Roman Cheplyaka <roma(a)ro-che.info> wrote: > > * Heinrich Apfelmus <apfelmus(a)quantentunnel.de> [2013-03-15 10:38:37+0100] > >> Duncan Coutts wrote: > >> >Hi folks, > >> > > >> >I want to give you advance notice that I would like to make Cabal depend > >> >on parsec. The implication is that GHC would therefore depend on parsec > >> >and thus it would become a core package, rather than just a HP package. > >> >So this would affect both GHC and the HP, though I hope not too much. > >> > > >> >[..] > >> > > >> >Why did I choose parsec? Practicality dictates that I can only use > >> >things in the core libraries, and the nearest thing we have to that is > >> >the parser lib that is in the HP. I tried to use happy but I could not > >> >construct a grammar/lexer combo to handle the layout (also, happy is not > >> >exactly known for its great error messages). > >> > >> Reuse is good, but the implication I'm worried about is this: Can I > >> upgrade the parsec package installed on my system by doing a user > >> install from hackage ? Without an implementation of more flexible > >> package installations (multiple versions installed simultaneously), > >> any dependency of GHC has its version number essentially set into > >> stone. > > > > We've had that working for a long time. Right now I even have multiple > > installed versions of Cabal-the-library itself. > > > > It's not that Parsec would be automatically linked into each executable. > > It's just that ghc-the-program would have Parsec linked into it. > > And ghc-the-library, which means that anything that uses > ghc-as-a-library (and indeed even Cabal-as-a-library) no longer has a > choice of which version of parsec they use. Right. But in this regard, GHC API and Cabal are no different from any other libraries that suffer from the same issue. (Except that it's hard to recompile GHC to use an alternative Parsec version.) And these are not exactly the most popular libraries either — so I doubt this change will have a large impact. Roman

1 0

Re: Advance notice that I'd like to make Cabal depend on parsec
by Roman Cheplyaka 15 Mar '13

15 Mar '13

* Heinrich Apfelmus <apfelmus(a)quantentunnel.de> [2013-03-15 10:38:37+0100] > Duncan Coutts wrote: > >Hi folks, > > > >I want to give you advance notice that I would like to make Cabal depend > >on parsec. The implication is that GHC would therefore depend on parsec > >and thus it would become a core package, rather than just a HP package. > >So this would affect both GHC and the HP, though I hope not too much. > > > >[..] > > > >Why did I choose parsec? Practicality dictates that I can only use > >things in the core libraries, and the nearest thing we have to that is > >the parser lib that is in the HP. I tried to use happy but I could not > >construct a grammar/lexer combo to handle the layout (also, happy is not > >exactly known for its great error messages). > > Reuse is good, but the implication I'm worried about is this: Can I > upgrade the parsec package installed on my system by doing a user > install from hackage ? Without an implementation of more flexible > package installations (multiple versions installed simultaneously), > any dependency of GHC has its version number essentially set into > stone. We've had that working for a long time. Right now I even have multiple installed versions of Cabal-the-library itself. It's not that Parsec would be automatically linked into each executable. It's just that ghc-the-program would have Parsec linked into it. Roman

1 0

building on Mac
by Kazu Yamamoto 14 Mar '13

14 Mar '13

Hello, These days I can "validate" GHC head on Mac. But to my surprise, I cannot build GHC head on Mac. I verified this with both 32bit and 64bit bootstrapping GHC on Mac. Any ideas? "inplace/bin/ghc-stage1" -static -prof -H32m -O -package-name hoopl-3.10.0.0 -hide-all-packages -i -ilibraries/hoopl/src -ilibraries/hoopl/dist-install/build -ilibraries/hoopl/dist-install/build/autogen -Ilibraries/hoopl/dist-install/build -Ilibraries/hoopl/dist-install/build/autogen -Ilibraries/hoopl/. -optP-include -optPlibraries/hoopl/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -split-objs -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -odir libraries/hoopl/dist-install/build -hidir libraries/hoopl/dist-install/build -stubdir libraries/hoopl/dist-install/build -hisuf p_hi -osuf p_o -hcsuf p_hc -c libraries/hoopl/src/Compiler/Hoopl/Show.hs -o libraries/hoopl/dist-install/build/Compiler/Hoopl/Show.p_o -dyno libraries/hoopl/dist-install/build/Compiler/Hoopl/Show.dyn_o "inplace/bin/ghc-stage1" -static -prof -H32m -O -package-name hoopl-3.10.0.0 -hide-all-packages -i -ilibraries/hoopl/src -ilibraries/hoopl/dist-install/build -ilibraries/hoopl/dist-install/build/autogen -Ilibraries/hoopl/dist-install/build -Ilibraries/hoopl/dist-install/build/autogen -Ilibraries/hoopl/. -optP-include -optPlibraries/hoopl/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -split-objs -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP -O2 -no-user-package-db -rtsopts -odir libraries/hoopl/dist-install/build -hidir libraries/hoopl/dist-install/build -stubdir libraries/hoopl/dist-install/build -hisuf p_hi -osuf p_o -hcsuf p_hc -c libraries/hoopl/src/Compiler/Hoopl/MkGraph.hs -o libraries/hoopl/dist-install/build/Compiler/Hoopl/MkGraph.p_o -dyno libraries/hoopl/dist-install/build/Compiler/Hoopl/MkGraph.dyn_o ghc-stage1: could not execute: /usr/bin/gcc make[1]: *** [libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 --Kazu

3 5

LLVM 3.2 failure
by Geoffrey Mainland 14 Mar '13

14 Mar '13

Several people have mentioned that LLVM 3.2 works with GHC. That has not been my experience. Using the quick-llvm BuildFlavour and LLVM 3.2 on Linux 64-bit, the stage2 compiler fails for me. Running the test suite with the stage 1 compiler unfortunately does not reveal any likely culprits (only the tests that rely on stuff built as part of the stage 2 compiler fail). Has anyone gotten LLVM 3.2 to work with the quick-llvm BuildFlavour? Thanks, Geoff

4 21

TICKY_TICKY symbol in rts's C code
by Nicolas Frisby 14 Mar '13

14 Mar '13

I'm trying to enable some ticky counters for profiling the RTS code (eg in Storage.c:allocate). Much of the code was already in place, but disabled via CPP. I can enable the counters, but I'm having trouble making them only tick in the debug RTS. Can someone advise regarding the presence/accuracy of, say, the TICKY_TICKY symbol within the $(TOP)/includes/stg/Ticky.h file? Recap: * I use a macro in Storage.c to tick a ticky counter * The macro is #defined in stg/Ticky.h * I'd like the macro definition to be empty unless the Rts build way is DEBUG * There's this TICKY_TICKY symbol already floating around, so that seems like the right symbol to check * Thus: what do #include in stg/Ticky.h to make TICKY_TICKY accurate wrt to the build way? Maybe I'm dense at the moment, but trying some of the straight-forward options suggested by http://hackage.haskell.org/trac/ghc/wiki/Commentary/SourceTree/Includes didn't seem to help. Thanks.

2 1

build error on FreeBSD
by Kazu Yamamoto 14 Mar '13

14 Mar '13

Hello, When I build GHC head on FreeBSD, I got the following error. Is newSpark missing on FreeBSD? "inplace/bin/ghc-stage1" -fPIC -dynamic -H32m -O -package-name ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc libraries/ghc-prim/dist-install/build/GHC/Classes.dyn_o libraries/ghc-prim/dist-install/build/GHC/CString.dyn_o libraries/ghc-prim/dist-install/build/GHC/Debug.dyn_o libraries/ghc-prim/dist-install/build/GHC/Magic.dyn_o libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o libraries/ghc-prim/dist-install/build/GHC/IntWord64.dyn_o libraries/ghc-prim/dist-install/build/GHC/Tuple.dyn_o libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o libraries/ghc-prim/dist-install/build/cbits/debug.dyn_o libraries/ghc-prim/dist-install/build/cbits/longlong.dyn_o libraries/ghc-prim/dist-install/build/cbits/popcnt.dyn_o libraries/ghc-prim/dist-install/build/cbits/word2float.dyn_o -shared -dynamic -dynload deploy -no-auto-link-packages -o libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130312.so Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/local/bin/ld: libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.dyn_o: relocation R_X86_64_PC32 against undefined symbol `newSpark' can not be used when making a shared object; recompile with -fPIC /usr/local/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status gmake[1]: *** [libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130312.so] Error 1 gmake: *** [all] Error 2 --Kazu

2 4

SIMD/SSE support & alignment
by Nicolas Trangez 13 Mar '13

13 Mar '13

All, I've been toying with the SSE code generation in GHC 7.7 and Geoffrey Mainland's work to integrate this into the 'vector' library in order to generate SIMD code from high-level Haskell code. While working with this, I wrote some simple code for testing purposes, then compiled this into LLVM IR and x86_64 assembly form in order to figure out how 'good' the resulting code would be. First and foremost: I'm really impressed. Whilst there's most certainly room for improvement (one of them touched in this mail, though I also noticed unnecessary constant memory reads inside a tight loop), the initial results look very promising, especially taking into account how high-level the source code is. This is pretty amazing! As an example, here's 'test.hs': {-# OPTIONS_GHC -fllvm -O3 -optlo-O3 -optlc-O=3 -funbox-strict-fields #-} module Test (sum) where import Prelude hiding (sum) import Data.Int (Int32) import Data.Vector.Unboxed (Vector) import qualified Data.Vector.Unboxed as U sum :: Vector Int32 -> Int32 sum v = U.mfold' (+) (+) 0 v When compiling this into assembly (compiler/library version details at the end of this message), the 'sum' function yields (among other things) this code: .LBB2_3: # %c1C0 # =>This Inner Loop Header: Depth=1 prefetcht0 (%rsi) movdqu -1536(%rsi), %xmm1 paddd %xmm1, %xmm0 addq $16, %rsi addq $4, %rcx cmpq %rdx, %rcx jl .LBB2_3 The full LLVM IR and assembler output are attached to this message. Whilst this is a nice and tight loop, I noticed the use of 'movdqu', which is used for non-128bit aligned memory access in SSE code. For aligned memory, 'movdqa' can be used, and this can have a major performance impact. Whilst I understand why this code is currently generated as-is (also in other sample inputs), I wondered whether there are plans/approaches to tackle this. In some cases (e.g. in 'sum') this could be by using the scalar calculation at the beginning of the vector up until an aligned boundary, then use aligned access and handle the tail using scalars again, but I assume OTOH that's not trivial when multiple 'source' vectors are used in the calculation. This might even become more complex when using AVX code, which needs 256bit alignments. Whilst I can't propose an out-of-the-box solution, I'd like to point at the 'vector-simd' code [1] I wrote some months ago, which might propose some ideas. In this package, I created an unboxed vector-like type whose alignment is tracked at type level, and functions which consume a vector define the minimal required alignment. As such, vectors can be allocated at the minimal alignment they're required to be, throughout all code using them. As an example, if I'd use this code (OTOH): sseFoo :: (Storable a, AlignedToAtLeast A16 o1, AlignedToAtLeast A16 o2) => Vector o1 a -> Vector o2 a sseFoo = undefined avxFoo :: (Storable a, AlignedToAtLeast A32 o1, AlignedToAtLeast A32 o2, AlignedToAtLeast A32 o3) => Vector o1 a -> Vector o2 a -> Vector o3 a avxFoo = undefined the type of combinedFoo v = avxFoo sv sv where sv = sseFoo v would automagically be combinedFoo :: (Storable a, AlignedToAtLeast A16 o1, AlignedToAtLeast A32 o2) => Vector o1 a -> Vector o2 a and when using this v1 = combinedFoo (Vector.fromList [1 :: Int32, 2, 3, 4, 5, 6, 7, 8]) the allocated argument vector (result of Vector.fromList) will be 16byte-aligned as expected/required for the SSE function to work with unaligned loads internally (assuming no unaligned slices are supported, etc), whilst the intermediate result of 'sseFoo' ('sv') will be 32-byte aligned as required by 'avxFoo'. Attached: test.ll and test.s, compilation results of test.hs using $ ghc-7.7.20130302 -keep-llvm-files -package-db=cabal-dev/packages-7.7.20130302.conf -fforce-recomp -S test.hs GHC from HEAD/master compiled on my Fedora 18 system using system LLVM (3.1), 'primitive' 8aef578fa5e7fb9fac3eac17336b722cbae2f921 from git://github.com/mainland/primitive.git and 'vector' e1a6c403bcca07b4c8121753daf120d30dedb1b0 from git://github.com/mainland/vector.git Nicolas [1] https://github.com/NicolasT/vector-simd

4 11

Re: [GHC] #7766: equality constraints exposed by patterns mess up constraint inference
by Gabor Greif 13 Mar '13

13 Mar '13

Hi Simon, okay, I see how a type signature will help in that case, but it is unclear where to add one in this (even simpler) example: {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} data Nat = S Nat | Z data Nat' (n :: Nat) where S' :: Nat' n -> Nat' (S n) Z' :: Nat' Z main :: IO () main = do case S' Z' of (S' Z') -> putStrLn "yep" -- see error message below... -- _ -> putStrLn "yep" -- works! return () {- [1 of 1] Compiling Main ( pr7766.hs, pr7766.o ) pr7766.hs:11:23: Couldn't match type `a0' with `()' `a0' is untouchable inside the constraints (n ~ 'Z) bound by a pattern with constructor Z' :: Nat' 'Z, in a case alternative at pr7766.hs:11:16-17 Expected type: IO a0 Actual type: IO () In the return type of a call of `putStrLn' In the expression: putStrLn "yep" In a case alternative: (S' Z') -> putStrLn "yep" -} Can we reopen the PR with this test? (Distilled from real code I have and which fails as of recently.) Thanks and cheers, Gabor On 3/13/13, GHC <cvs-ghc(a)haskell.org> wrote: > #7766: equality constraints exposed by patterns mess up constraint > inference > ----------------------------------------+----------------------------------- > Reporter: heisenbug | Owner: > Type: bug | Status: closed > Priority: normal | Milestone: > Component: Compiler | Version: 7.7 > Resolution: invalid | Keywords: > Os: Unknown/Multiple | Architecture: Unknown/Multiple > Failure: GHC rejects valid program | Difficulty: Unknown > Testcase: | Blockedby: > Blocking: | Related: > ----------------------------------------+----------------------------------- > Changes (by simonpj): > > * status: new => closed > * difficulty: => Unknown > * resolution: => invalid > > > Comment: > > This is by design. Type inference in the presence of GADTs is tricky! > > If you give the signature `main :: IO ()` it works fine. But here you are > asking GHC to ''infer'' the type of `main`. (Remember, Haskell doesn't > insist on `IO ()`; the `main` function can have type `IO Char`.) > > Becuase you are pattern matching against GADTs there are equalities in > scope, so GHC declines to contrain the type of `main`. In this particular > case there is only one answer, but that's very hard to figure out, so we > fail conservatively. > > Bottom line: use type signatures when pattern matching on GADTs. > > Simon > > -- > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7766#comment:1> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 2

RE: [GHC] #6135: Unboxed Booleans
by Simon Peyton-Jones 13 Mar '13

13 Mar '13

Ben Would you like to take a look, since you initiated this :-). We need a definite win to make it worth it. Simon | -----Original Message----- | From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets- | bounces(a)haskell.org] On Behalf Of GHC | Sent: 13 March 2013 14:19 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #6135: Unboxed Booleans | | #6135: Unboxed Booleans | ---------------------------------+-------------------------------------- | ---------------------------------+---- | Reporter: benl | Owner: jstolarek | Type: feature request | Status: new | Priority: normal | Milestone: 7.8.1 | Component: Compiler | Version: 7.4.1 | Keywords: | Os: Unknown/Multiple | Architecture: Unknown/Multiple | Failure: None/Unknown | Difficulty: Unknown | Testcase: | Blockedby: | Blocking: | Related: #605 | | ---------------------------------+-------------------------------------- | ---------------------------------+---- | | Comment(by jstolarek): | | I implemented a prototype version of new comparison primops. They | compare two `Int#`s but as a result they return either `0#` (denoting | False) or `1#` (denoting True) instead of returning a `Bool`. Now the | results of comparing can be combined using bitwise `orI#`, `andI#`, | `xorI#` and `notI#` primops, which addresses the original problem that | was reported (at least partially). I'm attaching patches for GHC and | the testsuite (includes some cleanup of my other code for testing | primops). These patches are for review and discussion purposes - they | are not yet ready for integration because they don't contain primops | for comparing values of type `Word#`, `Float#` and `Double#`. I will | implement comparisons for these types once I am certain that I got | things right with `Int#`. | Feedback will be much appreciated. | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:21> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0