- ghc-devs - Haskell.org

make install (at git ef01794) still fails
by Tuncer Ayaz 29 Aug '13

29 Aug '13

I think the last time 'make install' worked for me was sometime in February or March 2013. The build succeeds but 'make install' fails. Is this normal? git rev ef01794 linux i386 glibc 2.18 gcc 4.8.1 mk/build.mk: BuildFlavour = perf V = 0 $ perl boot $ ./configure --prefix=/tmp/ghc/7.7.20130827 $ make $ make install [...] Installing library in /tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/haskell2010-1.1.1.0 "/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg" --force --global-package-db "/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/package.conf.d" update rts/dist/package.conf.install /tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg: error while loading shared libraries: libHSbin-package-db-0.0.0.0-ghc7.7.20130827.so: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 Related: http://www.haskell.org/pipermail/ghc-devs/2013-March/000822.html http://www.haskell.org/pipermail/ghc-devs/2013-April/000995.html

1 1

FW: [GHC] #8186: Parallel comprehensions not allowed in Template Haskell quotes
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

With Gitolite, the Trac tickets now get messages like this: Comment (by Richard Eisenberg <eir@…>): In [changeset:382f601406b11b7d4fdc72d773c6060372f1fbb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="382f601406b11b7d4fdc72d773c6060372f1fbb3" Fix Trac #8186. Parallel list comprehensions are now handled in DsMeta. }}} But they used to get messages like this (like git log --stat) commit ef017944600cf4e153aad686a6a78bfb48dea67a Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Aug 27 15:48:02 2013 +0100 Comments only, relating to #8166 fix compiler/codeGen/StgCmm.hs | 7 ++----- compiler/codeGen/StgCmmExpr.hs | 7 ++++--- compiler/codeGen/StgCmmMonad.hs | 10 +++++++++- 3 files changed, 15 insertions(+), 9 deletions(-) I liked the old version: the author is more explicit the modified files are listed if the patch is small you see it all Might it be possible to revert? Simon

2 2

Backward compatibility
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

Dear Core Libraries Committee In addition to seeking your guidance about the comparison-primop question (a decision in the next few days would be most welcome), there are of course other breaking changes in GHC 7.8. High on the list is Typeable (see http://ghc.haskell.org/trac/ghc/ticket/8132) which has become polykinded, which is SO much better. Also, to guarantee the type-soundness of Typeable, we want to make it an error to use hand-rolled instances, rather than "deriving( Typeable )". The latter is very common anyhow, and the hand-rolled ones mostly use Typeable1 which is now heavily deprecated. There's a compatibility module Data.OldTypeable, but you'd have to import it to get the old behaviour. It's very difficult to really provide a "bumpless transfer", which is why Michael's idea of a compatibility package might be worth exploring. Anyway this is just a heads-up. Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0

Haskell.org down?
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

Haskell.org looks down from here. Also ghc.haskell.org. I've tried http://www.downforeveryoneorjustme.com, which agrees. Does anyone know what is going on? Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 2

Buidling profiled fails
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

I try "sh validate" with profiled libraries and get libraries/dph/ghc.mk:134: *** Cannot build profiled GHC with DPH; try deleting libraries/dph and trying again. Stop. So I obediently remove libraries/dph, and try again. But that fails too: Error: libraries/dph/LICENSE doesn't exist. Maybe you haven't done './sync-all get'? at boot line 74, <PACKAGES> line 84. Seems a bit Catch-22 ish. I'm not sure how to fix this. Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

2 4

RE: GHC TypeFamilies extension
by Simon Peyton-Jones 28 Aug '13

28 Aug '13

We could do that, but personally I don't think it's worth it. I'm ccing ghc-devs in case anyone has a strong opinion. Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 27 August 2013 21:45 | To: Simon Peyton-Jones; Dimitrios Vytiniotis | Cc: Stephanie Weirich | Subject: GHC TypeFamilies extension | | Hi Simon, Dimitrios, | | Among the various responses I've gotten to closed type families was a | complaint (made by a fellow Penn student, Daniel Wagner) about | extensions that change their meaning over time. Here is why: If a | package requires the use of a certain extension, it can declare the | extension in the cabal file, so that end users get a nice error message | if their GHC is out of date. However, if a package uses closed type | families, no such declaration is possible; an old GHC will just die with | a parse error. There are ways to insist on a certain version of GHC or a | version of the base library, but that doesn't seem great, either. | | On the other hand, I'm loathe to add yet another extension | ClosedTypeFamilies, forcing yet another pragma at the top of | programmers' files. | | Instead, we came up with this intermediate solution: | - Introduce two new extensions, OpenTypeFamilies and ClosedTypeFamilies | - TypeFamilies would imply both of these | - Appropriate checks would be made and error messages improved | | Now, users can still use TypeFamilies to get both flavors of type | families, but a package maintainer can specify ClosedTypeFamilies in a | cabal file to control which versions of GHC are usable. | | I'm still not 100% convinced this is the right idea, but there is enough | sense in it to ask. | | What do you think? If you all think this is a good enough idea, I'll | forward to glasgow-haskell-users for a wider discussion. | | Thanks, | Richard

1 0

HEAD build fails on OS X
by Andreas Voellmy 27 Aug '13

27 Aug '13

I got a fresh copy of HEAD today, and the build failed. The failing command is: $ cd libraries && sh gen_contents_index --intree haddock: internal error: /Users/andreas/repos/temp-ghc-2/ghc-build/inplace/lib/html/Ocean.std-theme/hslogo-16.png: copyFile: does not exist (No such file or directory) I have not yet had time to look into this, but hopefully someone knows what happened here. -Andi

7 17

Re: Getting rid of HEAP_ALLOCED
by Simon Marlow 27 Aug '13

27 Aug '13

On 27 Aug 2013 19:59, "Edward Z. Yang" <ezyang(a)cs.stanford.edu> wrote: > > Excerpts from Simon Marlow's message of Sun Aug 25 12:56:06 -0700 2013: > > You can arrange that all the indirections end up next to each other by > > putting them in a special section. Then you can traverse the contents > > of the section so long as you have a symbol at the beginning and the > > end, or something like that. There are other ways to do it, such as > > having the module initialisation code register something with the RTS. > > If I understand correctly, this is not true if you do something like > dynamic linking, in which case each dynamic library will have its > own indirection region. So in that case, every library should register > its boundary symbols with the RTS. Yes, sorry I forgot to mention that. Alternatively having each module register its table might be easier. Cheers Simon > Edward

1 0

code generation and backends Re: Design discussion for atomic primops to land in 7.8
by Carter Schonwald 27 Aug '13

27 Aug '13

Austin also raises an important point: Its high time we explore changes to the ABI/per architecture calling convention and how they might impact performance. I think this is something worth exploring after the 7.8 release (but not in the next month of prerelease engineering, though I need to suss out some of that a bit more with the parties who care) I had started working on a backwards compatible ABI change for llvm a few months back that I could easily get LLVM folks to merge in, but I'd rather only give the LLVM folks 1 set of ABI change patches within a 6month period, where we've had the time to experiment with breaking changes as an option too, rather than given them a partial patch now, and then a breaking changes calling convention patch a few months from now. (because if we don't bundle LLVM with GHC, we need to actually tie ABI versions to LLVM major version releases, which isn't a problem, but just requires thoughtful cooperation and such) cheers -Carter On Tue, Aug 27, 2013 at 12:51 PM, Austin Seipp <aseipp(a)pobox.com> wrote: > To do this, IMO we'd also really have to start shipping our own copy > of LLVM. The current situation (use what we have configured or in > $PATH) won't really become feasible later on. > > On platforms like ARM where there is no NCG, the mismatches can become > super painful, and it makes depending on certain features of the IR or > compiler toolchain (like an advanced, ISA-aware vectorizer in LLVM > 3.3+) way more difficult, aside from being a management nightmare. > > Fixing it does require taking a hit on things like build times, > though. Or we could use binary releases, but we occasionally may want > to tweak and/or fix things. If we ship our own LLVM for example, it's > reasonable to assume sometime in the future we'll want to change the > ABI during a release. > > This does bring other benefits. Max Bolingbroke had an old alias > analysis plugin for LLVM that made a noticeable improvement on certain > kinds of programs, but shipping it against an arbitrary LLVM is > infeasible. Stuff like this could now be possible too. > > In a way, I think there's some merit to having a simple, integrated > code generator that does the correct thing, with a high performance > option as we have now. LLVM is a huge project, and there's definitely > some part of me that thinks this may not lower our complexity budget > as much as we think, only shift parts of it around ('second rate' > platforms like PPC/ARM expose way more bugs in my experience, and > tracking them across such a massive surface area can be quite > difficult.) It's very stable and well tested, but an unequivocal > dependency on hundreds of thousands of lines of deeply complex code is > a big question no matter what. > > But, the current NCG isn't that 'simple correct thing' either, though. > I think it's easily one of the least understood parts of the compiler > with a long history, it's rarely refactored or modified (very unlike > other parts,) and it's maintained only as necessary. Which doesn't > bode well for its future in any case. > > > On Mon, Aug 26, 2013 at 3:19 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: > > On 26/08/13 08:17, Ben Lippmeier wrote: > >> > >> > >>> > Well, what's the long term plan? Is the LLVM backend going to > >>> become the only backend at some point? > >>> > >>> I wouldn't argue against ditching the NCG entirely. It's hard to > >>> justify fixing NCG performance problems when fixing them won't > >>> make the NCG faster than LLVM, and everyone uses LLVM anyway. > >>> > >>> We're going to need more and more SIMD support when processors > >>> supporting the Larrabee New Instructions (LRBni) appear on > >>> people's desks. At that time there still won't be a good enough > >>> reason to implement those instructions in the NCG. > >>> > >>> I hope to implement SIMD support for the native code gen soon. It's > >>> not a huge task and having feature parity between LLVM and NCG would > >>> be good. > >> > >> > >> Will you also update the SIMD support, register allocators, and calling > >> conventions in 2015 when AVX-512 lands on the desktop? On all supported > >> platforms? What about support for the x86 vcompress and vexpand > >> instructions with mask registers? What about when someone finally asks > >> for packed conversions between 16xWord8s and 16xFloat32s where you need > >> to split the result into four separate registers? LLVM does that > >> automatically. > >> > >> I've been down this path before. In 2007 I implemented a separate graph > >> colouring register allocator in the NCG to supposably improve GHC's > >> numeric performance, but the LLVM backend subsumed that work and now > >> having two separate register allocators is more of a maintenance burden > >> than a help to anyone. At the time, LLVM was just becoming well known, > >> so it wasn't obvious that implementing a new register allocator was a > >> largely a redundant piece of work -- but I think it's clear now. I was > >> happy to work on the project at the time, and I learned a lot from it, > >> but when starting new projects now I also try to imagine the system that > >> will replace the one I'm dreaming of. > >> > >> Of course, you should do what interests you -- I'm just pointing out a > >> strategic consideration. > > > > > > The existence of LLVM is definitely an argument not to put any more > effort > > into backend optimisation in GHC, at least for those optimisations that > LLVM > > can already do. > > > > But as for whether the NCG is needed at all - there are a few ways that > the > > LLVM backend needs to be improved before it can be considered to be a > > complete replacement for the NCG: > > > > 1. Compilation speed. LLVM approximately doubles compilation time. > Avoiding > > going via the textual intermediate syntax would probably help here. > > > > 2. Shared library support (#4210, #5786). It works (or worked?) on a > couple > > of platforms. But even on those platforms it generated worse code than > the > > NCG due to using dynamic references for *all* symbols, whereas the NCG > knows > > which symbols live in a separate package and need to use dynamic > references. > > > > 3. Some low-level optimisation problems (#4308, #5567). The LLVM backend > > generates bad code for certain critical bits of the runtime, perhaps due > to > > lack of good aliasing information. This hasn't been revisited in the > light > > of the new codegen, so perhaps it's better now. > > > > Someone should benchmark the LLVM backend against the NCG with new > codegen > > in GHC 7.8. It's possible that the new codegen is getting a slight boost > > because it doesn't have to split up proc points, so it can do better code > > generation for let-no-escapes. (It's also possible that LLVM is being > > penalised a bit for the same reason - I spent more time peering at > > NCG-generated code than LLVM-generated code). > > > > These are some good places to start if you want to see GHC drop the NCG. > > > > Cheers, > > Simon > > > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs >

1 0

Changes in Hoopl
by Jan Stolarek 27 Aug '13

27 Aug '13

Me and Simon PJ had some discussion about modifying Hoopl. I summarized that discussion on a wiki page: http://ghc.haskell.org/trac/ghc/wiki/Hoopl/Cleanup I'd like to implement changes once there's a consensus on which changes exactly do we want in Hoopl. Janek

4 8