- ghc-devs - Haskell.org

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

abount template haskell's pretty print: ($$$) x y = ...
by PAF01143＠nifty.ne.jp 27 Aug '13

27 Aug '13

Hello. I'm Yoshikuni Jujo. I want to correct ppr_dec of Language.Haskell.TH.Ppr. Now: ppr $ FunD (mkName "$$") [Clause [] (NormalB $ VarE $ mkName "x") []] => $$ = x but I want: ppr $ FunD (mkName "$$") [Clause [] (NormalB $ VarE $ mkName "x") []] => ($$) = x I'll send patch. -- module Language.Haskell.TH.Ppr ... isOp :: String -> Bool isOp = all (`elem` "!#$%&*+./<=>?@\\^|-~:") ppr_dec _ (FunD f cs) | isOp $ nameBase f = vcat $ map (\c -> parens (ppr f) <+> ppr c) cs | otherwise = vcat ... ... ppr_dec _ (SigD f t) | isOp $ nameBase f = parens (ppr f) <+> text "::" <+> ppr t | otherwise = ppr f ...

2 1

make -jN loops on Windows
by Simon Peyton-Jones 27 Aug '13

27 Aug '13

I have a nice new 64-bit Windows 8 laptop. But when I say make -j2 then it launches a couple processes (which I think complete fine) and then locks up with 'make' consuming 25-35% of a CPU, but nothing happening. No further activity for 30 mins. This is msys 'make', version 3.81, which worked fine on my old (32-bit) laptop. Things work ok without -j. But validate uses -j (how to disable that?). Does anyone have a clue about how I might find out what is going on? I don't think msys has 'strace'. Thanks 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

about template haskell's pretty print: 3 % 5 -> 3 / 5
by Yoshikuni Jujo 27 Aug '13

27 Aug '13

Hello! I think it's better that the ghc can read what is printed by pretty printer. Now: pprLit 0 (RationalL 3.5) => 7 % 2 I want: pprLit 0 (RationalL 3.5) => 7 / 2 I'll send patch --- pprLit i (RationalL rat) = parensIf (i > noPrec) $ integer (numerator rat) <+> char '/' <+> integer (denominator rat)

1 0

RE: Haskell platform
by Simon Peyton-Jones 26 Aug '13

26 Aug '13

They [happy,alex] are in <platform>/lib/extralibs/bin now for some reason. The HP installer should have added that to the PATH though. Oh, thank you! I never thought of looking there. The installer didn't add it. Mark, it would be amazingly helpful if http://www.haskell.org/platform/ had clear documentation about this! At the moment * It's hard to find an authoritative list of what's in (a particular version of) HP. I tried the "Comprehensive" link on the HP page, leading to http://www.haskell.org/platform/contents.html, and that did mention Happy and Alex, but in a general kind of way. * I tried "Documentation" which leads here http://lambda.haskell.org/platform/doc/current/start.html, but that doesn't have a list of what's in it. (For the libraries part you can kind-of deduce it from the right hand column of the "libraries" link http://lambda.haskell.org/platform/doc/current/frames.html, but it's pretty indirect. * I couldn't find a list of what executable programs should be installed. * It would be really great to know where those executables live. None of this is hard; maybe just no one has asked. Thanks! Simon From: Niklas Larsson [mailto:metaniklas@gmail.com] Sent: 23 August 2013 02:10 To: Simon Peyton-Jones Subject: Re: Haskell platform Hi! They are in <platform>/lib/extralibs/bin now for some reason. The HP installer should have added that to the PATH though. Niklas 2013/8/23 Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Urk. The Haskell Platform claims to include Happy and Alex. http://www.haskell.org/platform/contents.html But 2013.2.0.0 doesn't. Is that intentional? That's a big problem for people using HP to build GHC. I'm installing 2012.4.0.0 in the hope that it does. No, nor does 2012.2 Am I just being stupid here? Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://www.haskell.org/mailman/listinfo/ghc-devs

2 2