- ghc-devs - Haskell.org

Can't build a ghc cloned from github
by Bryan O'Sullivan 06 Jul '13

06 Jul '13

There appears to be a bad ref on the server for the Cabal repo: == running git submodule update error: Unable to find b4d0c0f2846542dc2e2df189fe145a56ac9b30b6 under http://darcs.haskell.org/libraries/Cabal.git Cannot obtain needed object b4d0c0f2846542dc2e2df189fe145a56ac9b30b6 while processing commit e7e7ce1029707a67d26e6dc29de11141734898e3. error: Fetch failed. Unable to fetch in submodule path 'libraries/Cabal' git failed: 256 at ./sync-all line 116.

1 0

Question about the new codegen in GHC
by Jan Stolarek 04 Jul '13

04 Jul '13

Hi Simon, as part of my internship at MSR I'm working on optimizing the new code generator. My starting point is Krzysztof Woś's project "Low-level code optimizations in the Glasgow Haskell Compiler" [1]. Right now I'm trying to figure out which of the described optimisations are currently implemented and which ones are not. Looking at a simple factorial program, which was used throughout Krzysztof's project, I see that the code gets optimized properly. Does this mean that all the optimizations described in that work are implemented? Two things I'm particularily interested in are: * do tail calls always call the entry code, or can it happen that a tail call is done indirectly (e.g. via another label that does immediate jump to the entry code)? * commentary on the wiki says that Common Block Elimination "essentially implements the Adams optimisation, we believe". Is that really the case, or are there situations when two similar blocks could be eliminated by Adams optimization, but will not be eliminated by CBE? Janek [1] http://research.microsoft.com/en-us/um/people/simonpj/tmp/wos-diss-draft.pdf

2 1

status of template haskell + cross compiling plans for 7.8?
by Carter Schonwald 04 Jul '13

04 Jul '13

Hey All, Whats the story planned for template haskell + cross compiler support come ghc 7.8? I understand theres a lot of Template Haskell design underway, some of which will help support tools like Manuel's Inline-Objective-C work. Does this mean that factored out within this reorganization is a better story for cross compilation? Especially since one kill "app" for the Inline-Objective-C template haskell work would be writing IOS applications. Though I guess that also touches on the need to sort out supporting "FAT" ARM binaries too, right? This intersects with a few different large subsets of tickets, so i'm not sure if any single ticket is the right fora for this question. thanks! -Carter

9 13

RE: [commit: ghc] master: Comment out a leftover pprTrace (a5b7ee5)
by Simon Peyton-Jones 04 Jul '13

04 Jul '13

Actually that pprTrace is deliberate! Something is wrong if we have more than 10 iterations in the fixpoint loop and I'd like to know. Actually this *is* happening right now (I should make a ticket). I know why but have not worked out a good way to fix it. And POPL is pressing. Anyway leave it for now and I'll make a ticket S | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Gabor Greif | Sent: 03 July 2013 21:58 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Comment out a leftover pprTrace (a5b7ee5) | | Repository : http://darcs.haskell.org/ghc.git/ | | On branch : master | | https://github.com/ghc/ghc/commit/a5b7ee5fc26ac322e7dc79de96e478cde81964 | 0c | | >--------------------------------------------------------------- | | commit a5b7ee5fc26ac322e7dc79de96e478cde819640c | Author: Gabor Greif <ggreif(a)gmail.com> | Date: Wed Jul 3 22:56:23 2013 +0200 | | Comment out a leftover pprTrace | | >--------------------------------------------------------------- | | compiler/stranal/DmdAnal.lhs | 14 +++++++------- | 1 file changed, 7 insertions(+), 7 deletions(-) | | diff --git a/compiler/stranal/DmdAnal.lhs b/compiler/stranal/DmdAnal.lhs | index 572a39d..0aff8ff 100644 | --- a/compiler/stranal/DmdAnal.lhs | +++ b/compiler/stranal/DmdAnal.lhs | @@ -26,7 +26,7 @@ import Data.List | import DataCon | import Id | import CoreUtils ( exprIsHNF, exprType, exprIsTrivial ) | -import PprCore | +-- import PprCore | import TyCon | import Type ( eqType ) | -- import Pair | @@ -536,12 +536,12 @@ dmdFix top_lvl env orig_pairs | -- iteration of sigs. | | | n >= 10 | - = pprTrace "dmdFix loop" (ppr n <+> (vcat | - [ text "Sigs:" <+> ppr [ (id,lookupVarEnv (sigEnv env) | id, | - lookupVarEnv | (sigEnv env') id) | - | (id,_) <- pairs], | - text "env:" <+> ppr env, | - text "binds:" <+> pprCoreBinding (Rec pairs)])) | + = -- pprTrace "dmdFix loop" (ppr n <+> (vcat | + -- [ text "Sigs:" <+> ppr [ (id,lookupVarEnv | (sigEnv env) id, | + -- lookupVarEnv | (sigEnv env') id) | + -- | (id,_) <- pairs], | + -- text "env:" <+> ppr env, | + -- text "binds:" <+> pprCoreBinding (Rec | pairs)])) | (env, lazy_fv, orig_pairs) -- Safe output | -- The lazy_fv part is really important! orig_pairs has no | strictness | -- info, including nothing about free vars. But if we have | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

FW: [GHC] #8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM
by Simon Peyton-Jones 04 Jul '13

04 Jul '13

Dear Tim Might you have a moment to verify this guy's STM bug report and fix? Thanks Simon -----Original Message----- From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC Sent: 03 July 2013 22:11 Cc: ghc-tickets(a)haskell.org Subject: [GHC] #8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM #8035: STM transaction left open if there is an orElse on the path between throwSTM and catchSTM -----------------------------+---------------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: stm rts Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ main = join $ atomically $ do catchSTM (throwSTM ThreadKilled `orElse` return (putStrLn "wtf")) (\(e::SomeException) -> return (putStrLn "ok")) }}} This program crashes with a segmentation fault. Tested with GHC HEAD. I attach the testcase and my proposed fix for the issue. I've run the fast testsuite with the proposed fix without new defects. On the other hand I'm very new to GHC, so while I'm sure in the defect and the test, the fix may be bogus. Thanks goes to Mihály Bárász for discovering the issue. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8035> 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

add FastString.string_table to CoreMonad.reinitializeGlobals?
by Nicolas Frisby 04 Jul '13

04 Jul '13

Was the FastString Table intentionally left out of the reinitializeGlobals mechanism? This has lead to some confusion in using pieces of the front-end within GHC plugins. Is there foreseeable harm in adding it? I've done so locally, and minimal testing seems fine. Thanks.

2 2

Intel Functional Language compiler (Was: PSA: GHC can now be built with Clang)
by Ryan Newton 04 Jul '13

04 Jul '13

This came up randomly because of a typo, but rather than respond for them I've changed the thread name to something descriptive and copies the authors of the paper. The small bit that I know: - It is a new backend that takes Core from GHC and does the rest itself (including having a non-GHC runtime). - There are some patches to GHC (somewhere?) to support a new kind of initialization-only vector. - The IFLC backend uses a strict intermediate representation and performs auto-vectorization on loops. In particular, the paper evaluates the technique on loops from (slightly modified) REPA and vector library code. - It handles a pretty sizable subset of the language, but is missing some things (e.g. asynchronous exceptions). - It is not released yet On Tue, Jul 2, 2013 at 7:54 PM, Carter Schonwald <carter.schonwald(a)gmail.com > wrote: > What branch is that work in? I've not seen mention of it in the commit > logs. I'd really love to see how they're Doing it. > > Likewise, it's worth remarking that a carefullywritten simd primop that > explicitly uses the instruction intrinsics can easily be 1.5-2x faster than > auto vectorized simd code. I've some examples I tested for matrix > multiplication where the performance is robustly In that range. > > > On Tuesday, July 2, 2013, Ryan Newton wrote: > >> Gosh, sorry, yes it's not obvious from the list of accepted papers: >> >> "Automatic SIMD Vectorization for Haskell" Leaf Petersen, Dominic Orchard >> and Neal Glew >> One of the authors has a link for it but it appears there's no preprint >> up yet: >> http://www.leafpetersen.com/leaf/publications.htm >> >> >> >> >> >> >> On Tue, Jul 2, 2013 at 5:36 AM, Nicolas Trangez <nicolas(a)incubaid.com>wrote: >> >>> On Mon, 2013-07-01 at 12:05 -0400, Ryan Newton wrote: >>> > Err, GCC replacement. But, ironically, GHC [backend] replacement as >>> well, >>> > as of the recent ICFP paper. >>> >>> Got a link or reference? >>> >>> Nicolas >>> >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >>

2 1

Re: [commit: base] master: Remove uses of RecordWildCards in GHC.Event.TimerManager (1f81187)
by Simon Marlow 03 Jul '13

03 Jul '13

On 08/06/13 19:14, Ian Lynagh wrote: > commit 1f81187e63dcd4f160cfd1ce62efc4b1d26603dc > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Sat Jun 8 18:54:23 2013 +0100 > > Remove uses of RecordWildCards in GHC.Event.TimerManager curious: why? > @@ -174,10 +173,10 @@ finished :: TimerManager -> IO Bool > finished mgr = (== Finished) `liftM` readIORef (emState mgr) > > cleanup :: TimerManager -> IO () > -cleanup TimerManager{..} = do > - writeIORef emState Finished > - I.delete emBackend > - closeControl emControl > +cleanup mgr = do > + writeIORef (emState mgr) Finished > + I.delete (emBackend mgr) > + closeControl (emControl mgr) Note that in general this transformation might lead to worse code if the field selectors aren't used strictly. (I don't think it's the case here, but I didn't check the rest of the diff.) Cheers, Simon

2 1

Simd ghc and llvm Re: PSA: GHC can now be built with Clang
by Carter Schonwald 03 Jul '13

03 Jul '13

Which reminds me: should we look into getting a patch into llvm'd ghc calling convention so that on avx2 capable machines so we can eventually add support for the 256bit Ymm resisters and primops to ghc? We really should make sure it's patched in on the llvm side first. I believe it'd be a 2 line patch, might even be something we could get into the next llvm point release if there's a clear agreement about it too. Thoughts? I'm happy to put a ticket on trac for this andor do the leg work to make it happen if everyone agrees. On Tuesday, July 2, 2013, Ryan Newton wrote: > Gosh, sorry, yes it's not obvious from the list of accepted papers: > > "Automatic SIMD Vectorization for Haskell" Leaf Petersen, Dominic Orchard > and Neal Glew > One of the authors has a link for it but it appears there's no preprint up > yet: > http://www.leafpetersen.com/leaf/publications.htm > > > > > > > On Tue, Jul 2, 2013 at 5:36 AM, Nicolas Trangez <nicolas(a)incubaid.com<javascript:_e({}, 'cvml', 'nicolas(a)incubaid.com');> > > wrote: > >> On Mon, 2013-07-01 at 12:05 -0400, Ryan Newton wrote: >> > Err, GCC replacement. But, ironically, GHC [backend] replacement as >> well, >> > as of the recent ICFP paper. >> >> Got a link or reference? >> >> Nicolas >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org <javascript:_e({}, 'cvml', 'ghc-devs(a)haskell.org');> >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > >

1 3

PSA: GHC can now be built with Clang
by Austin Seipp 03 Jul '13

03 Jul '13

Hi all, As of commit 5dc74f it should now be possible to build a working stage1 and stage2 compiler with (an extremely recent) Clang. With some caveats. You can just do: $ CC=/path/to/clang ./configure --with-gcc=/path/to/clang $ make I have done this work on Linux. I don't expect much difficulty on Mac OS X, but it needs testing. Ditto with Windows, although Clang/mingw is considered experimental. The current caveats are: * The testsuite will probably fail everywhere, because of some warnings that happen during the linking phase when you invoke the built compiler. So the testsuite runner will probably be unhappy. Clang is very noisy about unused options, unlike GCC. That needs to be fixed somewhere in DriverPipeline I'd guess, but with some refactoring. * Some of the stage2 libraries don't build due to a Clang bug. These are vector/primitive/dph so far. * There is no buildbot or anything to cover it. You will need a very recent Clang. Due to this bug (preventing primitive etc from building,) you'll preferably want to use an SVN checkout from about 6 hours ago at latest: http://llvm.org/bugs/show_bug.cgi?id=16363 Hilariously, this bug was tripped on primitive's Data.Primitive.Types module due to some CPP weirdness. But even with a proper bugfix and no segfault, it still fails to correctly parse this same module with the same CPP declarations. I'm fairly certain this is another bug in Clang, but I might be wrong. I'm trying to isolate it. Unfortunately Clang/LLVM 3.3 was just released and it won't see bugfix releases. But it will *probably* work if we just get rid of the CPP tomfoolery in primitive. I'll be testing it in the next few days to see if we can get 3.3 supported. (I'm sort of kicking myself in the head for not doing this a week or two ago...) Anyway, there are some rough edges but it should be in shape for 7.8 I hope. It should be especially welcome for Mac users. (I'm also hoping modern Macs could even go all-clang-all-the-time if my fix for #7602 can go in soon...) PS. If you use ASSERT, I just fixed a lot of instances of using that macro, involving whitespace between the name and arguments (commit d8ee2b.) Clang does not forgive you for this. Should I note this anywhere for the future in the wiki or something? -- Regards, Austin - PGP: 4096R/0x91384671

8 16