- ghc-devs - Haskell.org

Re: [commit: ghc] master: Implement type family instance support for ":info" (#4175) (ca39e77)
by Gabriel Dos Reis 15 Mar '13

15 Mar '13

On Fri, Mar 15, 2013 at 10:55 AM, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: > Repository : http://darcs.haskell.org/ghc.git/ > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/ca39e777907f8b16d8ede82e040b6… I've noticed, for about a week now, that the link embedded in commit messages no longer work as Trac appears to be unable to resolve them :-(( -- Gaby

2 3

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

15 Mar '13

On Fri, 2013-03-15 at 12:37 +0800, Conrad Parker wrote: > On 14 March 2013 22:53, Duncan Coutts <duncan.coutts(a)googlemail.com> wrote: > > > > 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 > > When you say you've "made adjustments for" dodgy .cabal files in the > wild, do you mean that you'll send those maintainers patches that make > their cabal files less dodgy, or do you mean you've added hacks to > your parser to reproduce the quirky behaviour? The latter, but the egregiousness of the hacks is actually not too bad in the end. I don't find it revolting. For the worst examples I didn't make adjustments and those ones will break. I think I've made a reasonable judgement about the where to draw the line between the two. I can look into generating warnings in those cases (which is probably better than me emailing them). Duncan

1 0

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 15 Mar '13

15 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