- ghc-devs - Haskell.org

RFC: omit write barrier instructions unless '-threaded'
by Gabor Greif 01 Mar '13

01 Mar '13

Hi all, from what I gathered so far no emission of write barriers is needed when - running on a uniprocessor (-threaded or not) - running on a multiprocessor sans having linked with -threaded. Below patch suppresses the emission of 'lwsync' when no '-threaded' is specified on PPC only. So it does not cover both criteria above. It helps me a lot since I have a uniprocessor target that does not understand the 'lwsync' instruction (instruction is newer than core). Still, I have some doubts: o do we want to extend this approach to other archs? o possibly suppress the emission of MO_WriteBarrier in compiler/codeGen/StgCmmBind.hs (more care is needed to also cover compiler/cmm/CmmParse.y). Anyway this should be a safe first step, and I'd like to push it. When we find a general solution be can back this commit out. What do you think? Cheers, Gabor $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Feb 22 18:47:00 2013 +0100 Do not emit barriers on PPC unless we go the threaded way diff --git a/compiler/nativeGen/PPC/CodeGen.hs b/compiler/nativeGen/PPC/CodeGen.hs index 92eff36..6c33cca 100644 --- a/compiler/nativeGen/PPC/CodeGen.hs +++ b/compiler/nativeGen/PPC/CodeGen.hs @@ -1,9 +1,8 @@ - ----------------------------------------------------------------------------- -- -- Generating machine code (instruction selection) -- --- (c) The University of Glasgow 1996-2004 +-- (c) The University of Glasgow 1996-2013 -- ----------------------------------------------------------------------------- @@ -906,8 +905,10 @@ genCCall' -} -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ - = return $ unitOL LWSYNC +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ + = return (if WayThreaded `elem` ways dflags + then unitOL LWSYNC + else nilOL) genCCall' _ _ (PrimTarget MO_Touch) _ _ = return $ nilOL

3 8

Confusing commit messages about `type-nats`?
by Iavor Diatchki 28 Feb '13

28 Feb '13

Hello, I am receiving a bunch of commit messages for branch `type-nats`, that seem to be fake (i.e., by folks committing to other branches). Does any one know why that is? It seems to have started after my merge commit from yesterday, so did I mess something up? -Iavor

3 3

Build errors on HEAD
by Jan Stolarek 28 Feb '13

28 Feb '13

I get this error when building HEAD (8fe04eb): utils/ghc-pkg/Main.hs:881:3: No instance for (Bin.Binary (InstalledPackageInfo_ String)) arising from a use of `writeBinaryFileAtomic' Possible fix: add an instance declaration for (Bin.Binary (InstalledPackageInfo_ String)) In the first argument of `catchIO', namely `writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db))' In a stmt of a 'do' block: writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e In the expression: do { let filename = location db </> cachefilename; when (verbosity > Normal) $ infoLn ("writing cache " ++ filename); writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e } Anyone else getting this or is it just me? Janek

1 0

RE: [commit: base] master: Change rules for RealFrac methods to pointfree, so that they can also fire in pointfree use. (4036a1a)
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

I followed the link e http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e361… but got No handler matched request to /changeset/4036a1ae7a9694c9c69749ec8e36143c31bce976 I wonder why? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Daniel Fischer | Sent: 27 February 2013 13:58 | To: ghc-commits(a)haskell.org | Subject: [commit: base] master: Change rules for RealFrac methods to pointfree, | so that they can also fire in pointfree use. (4036a1a) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/base | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e36 | 143c31bce976 | | >--------------------------------------------------------------- | | commit 4036a1ae7a9694c9c69749ec8e36143c31bce976 | Author: Daniel Fischer <daniel.is.fischer(a)googlemail.com> | Date: Wed Feb 13 16:10:12 2013 +0100 | | Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. | | GHC/Int.hs | 96 +++++++++++++++++++++++++++++------------------ | ----------- | GHC/Word.hs | 72 ++++++++++++++++++++++---------------------- | 2 files changed, 84 insertions(+), 84 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 4036a1ae7a9694c9c69749ec8e36143c31bce976 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

RE: [commit: base] master: Change rules for RealFrac methods to pointfree, so that they can also fire in pointfree use. (4036a1a)
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

| Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. Good, thanks . But could you add a Note [Write rules in point-free style ~~~~~~~~~~~~~~~~~~~~~~ to explain what the motivating reason for the change is. Also an example or two. Perhaps there is a ticket that motivates it? Maybe refer to the Note from all the places where it is important? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Daniel Fischer | Sent: 27 February 2013 13:58 | To: ghc-commits(a)haskell.org | Subject: [commit: base] master: Change rules for RealFrac methods to pointfree, | so that they can also fire in pointfree use. (4036a1a) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/base | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e36 | 143c31bce976 | | >--------------------------------------------------------------- | | commit 4036a1ae7a9694c9c69749ec8e36143c31bce976 | Author: Daniel Fischer <daniel.is.fischer(a)googlemail.com> | Date: Wed Feb 13 16:10:12 2013 +0100 | | Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. | | GHC/Int.hs | 96 +++++++++++++++++++++++++++++------------------ | ----------- | GHC/Word.hs | 72 ++++++++++++++++++++++---------------------- | 2 files changed, 84 insertions(+), 84 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 4036a1ae7a9694c9c69749ec8e36143c31bce976 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

libtoolize
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

I've started to get this when I say "sh validate". What's up? Simon Booting . Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196. Booting libraries/base/ Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.

1 0

Top-level type signatures in TcGblEnv?
by Edsko de Vries 26 Feb '13

26 Feb '13

Dear Simon, other ghc devs, I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type [(SrcSpan, Id)] recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the tcg_binds :: LHsBinds Id, -- Value bindings in this module field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold: 1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them? 2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change? Thanks, Edsko

3 5

Fwd: RFC: omit write barrier instructions unless '-threaded'
by Gabor Greif 26 Feb '13

26 Feb '13

From: Gabor Greif <ggreif(a)gmail.com> Date: Tue, 26 Feb 2013 10:45:52 +0100 Subject: Re: RFC: omit write barrier instructions unless '-threaded' To: Simon Marlow <marlowsd(a)gmail.com> Cool, pushed https://github.com/ghc/ghc/commit/b7ae3cd9273da044384de4a327a4a5d71190129e Cheers, Gabor On 2/26/13, Simon Marlow <marlowsd(a)gmail.com> wrote: > On 25/02/13 22:07, Gabor Greif wrote: >> Thanks, this helped! >> >> >> Something like this? >> >> $ git show c3f5312 >> commit c3f53126fb0835cb21fc085e9b7cb5acb1ea1fba >> Author: Gabor Greif <ggreif(a)gmail.com> >> Date: Mon Feb 25 23:03:23 2013 +0100 >> >> Only emit %write_barrier primitive for THREADED_RTS >> >> diff --git a/includes/Cmm.h b/includes/Cmm.h >> index 1505b1c..bc5702c 100644 >> --- a/includes/Cmm.h >> +++ b/includes/Cmm.h >> @@ -583,6 +583,12 @@ >> #define OVERWRITING_CLOSURE(c) /* nothing */ >> #endif >> >> +#ifdef THREADED_RTS >> +#define prim_write_barrier prim %write_barrier() >> +#else >> +#define prim_write_barrier /* nothing */ >> +#endif >> + >> /* >> ----------------------------------------------------------------------------- >> Ticky macros >> >> -------------------------------------------------------------------------- >> */ >> diff --git a/rts/Updates.h b/rts/Updates.h >> index b4ff7d1..e6a2eb9 100644 >> --- a/rts/Updates.h >> +++ b/rts/Updates.h >> @@ -46,7 +46,7 @@ >> \ >> OVERWRITING_CLOSURE(p1); \ >> StgInd_indirectee(p1) = p2; \ >> - prim %write_barrier(); \ >> + prim_write_barrier; \ >> SET_INFO(p1, stg_BLACKHOLE_info); \ >> LDV_RECORD_CREATE(p1); \ >> bd = Bdescr(p1); \ >> >> >> Okay to commit? > > Yes, ok. > > Cheers, > Simon > > > >> Cheers, >> >> Gabor >> >> On 2/25/13, Simon Marlow <marlowsd(a)gmail.com> wrote: >>> On 25/02/13 14:53, Gabor Greif wrote: >>>> On 2/25/13, Simon Marlow <marlowsd(a)gmail.com> wrote: >>>>> On 24/02/13 20:40, Gabor Greif wrote: >>>>>> Hi all, >>>>>> >>>>>> from what I gathered so far no emission of write barriers is needed >>>>>> when >>>>>> - running on a uniprocessor (-threaded or not) >>>>>> - running on a multiprocessor sans having linked with -threaded. >>>>>> >>>>>> Below patch suppresses the emission of 'lwsync' when no '-threaded' >>>>>> is >>>>>> specified on PPC only. So it does not cover both criteria above. >>>>>> >>>>>> It helps me a lot since I have a uniprocessor target that does not >>>>>> understand the 'lwsync' instruction (instruction is newer than core). >>>>>> >>>>>> Still, I have some doubts: >>>>>> o do we want to extend this approach to other archs? >>>>>> o possibly suppress the emission of MO_WriteBarrier in >>>>>> compiler/codeGen/StgCmmBind.hs >>>>>> (more care is needed to also cover compiler/cmm/CmmParse.y). >>>>>> >>>>>> Anyway this should be a safe first step, and I'd like to push it. >>>>>> When >>>>>> we find a general solution be can back this commit out. >>>>>> >>>>>> What do you think? >>>>> >>>>> I don't think this is the right way to do it. The -threaded flag is >>>>> not >>>>> supposed to affect code generation, it only changes the RTS that gets >>>>> linked in. That is, you can compile all your code without -threaded >>>>> and >>>>> then just add -threaded at the link step, and it will work. >>>>> >>>> >>>> Hi Simon, >>>> >>>> thanks for your review! >>>> >>>>> Instead, use conditional compilation in the RTS so that the >>>>> write_barrer() calls are only present when THREADED_RTS is on. >>>> >>>> This is already done the way you suggest: >>>> >>>> #define write_barrier() /* nothing */ >>>> >>>> in includes/stg/SMP.h:368 >>>> >>>> Works perfectly, 'lwsync' only appears in .thr_*.o files. >>>> >>>> My problem stems from another call: >>>> >>>> emitPrimCall [] MO_WriteBarrier [] >>>> >>>> in compiler/codeGen/StgCmmBind.hs:614 >>>> >>>> or possibly >>>> >>>> callishMachOps = listToUFM $ >>>> map (\(x, y) -> (mkFastString x, y)) [ >>>> ( "write_barrier", MO_WriteBarrier ), >>>> ( "memcpy", MO_Memcpy ), >>>> ( "memset", MO_Memset ), >>>> ( "memmove", MO_Memmove ) >>>> -- ToDo: the rest, maybe >>>> ] >>>> >>>> in compiler/cmm/CmmParse.y:920 >>>> >>>> I doubt these files should be compiled with a dependency on >>>> THREADED_RTS, and indeed this symbol is only ever defined >>>> (-optc-DTHREADED_RTS) for the C compiler, and thus not available when >>>> compiling haskell source. >>>> >>>> So I am still stumped. >>>> >>>> The function where "lwsync" surfaces is: >>>> >>>> stg_marked_upd_frame_info which is rts/Updates.cmm:46. >>> >>> These come from rts/Updates.h:updateWithIndirection(), which expands to >>> some Cmm code that uses "prim %write_barrier()". So you want to use >>> some conditional compilation to make that prim %write_barrier() >>> disappear when THREADED_RTS is off. I suggest replacing it with >>> write_barrier(), and then #define write_barrier() in includes/Cmm.h. >>> >>> Cheers, >>> Simon >>> >>> >>>> This one is creating a blackhole (IISC) by means of StgCmmBind.hs:614. >>>> >>>> How can we go on from here? >>>> >>>> Cheers, >>>> >>>> Gabor >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> Simon >>>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> Gabor >>>>>> >>>>>> $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e >>>>>> commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e >>>>>> Author: Gabor Greif <ggreif(a)gmail.com> >>>>>> Date: Fri Feb 22 18:47:00 2013 +0100 >>>>>> >>>>>> Do not emit barriers on PPC unless we go the threaded way >>>>>> >>>>>> diff --git a/compiler/nativeGen/PPC/CodeGen.hs >>>>>> b/compiler/nativeGen/PPC/CodeGen.hs >>>>>> index 92eff36..6c33cca 100644 >>>>>> --- a/compiler/nativeGen/PPC/CodeGen.hs >>>>>> +++ b/compiler/nativeGen/PPC/CodeGen.hs >>>>>> @@ -1,9 +1,8 @@ >>>>>> - >>>>>> >>>>>> ----------------------------------------------------------------------------- >>>>>> -- >>>>>> -- Generating machine code (instruction selection) >>>>>> -- >>>>>> --- (c) The University of Glasgow 1996-2004 >>>>>> +-- (c) The University of Glasgow 1996-2013 >>>>>> -- >>>>>> >>>>>> ----------------------------------------------------------------------------- >>>>>> >>>>>> @@ -906,8 +905,10 @@ genCCall' >>>>>> -} >>>>>> >>>>>> >>>>>> -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ >>>>>> - = return $ unitOL LWSYNC >>>>>> +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ >>>>>> + = return (if WayThreaded `elem` ways dflags >>>>>> + then unitOL LWSYNC >>>>>> + else nilOL) >>>>>> >>>>>> genCCall' _ _ (PrimTarget MO_Touch) _ _ >>>>>> = return $ nilOL >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs(a)haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>> >>>>> >>> >>> > >

1 0

Why not rebase instead of merge?
by Geoffrey Mainland 25 Feb '13

25 Feb '13

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history. Thanks, Geoff

11 19

scheduleWaitThread looping
by Gabor Greif 25 Feb '13

25 Feb '13

I have finally have a cross compiler building, but encounter a new problem with a simple "Hello World" program not working. I get in GDB: Breakpoint 1, 0x102b4718 in startHeapProfTimer () (gdb) Continuing. Breakpoint 3, 0x102b4708 in stopHeapProfTimer () (gdb) Continuing. Breakpoint 1, 0x102b4718 in startHeapProfTimer () (gdb) bt #0 0x102b4718 in startHeapProfTimer () #1 0x1028d918 in scheduleWaitThread () #2 0x102b5dd0 in rts_evalLazyIO () #3 0x1028b674 in real_main () #4 0x1028b79c in hs_main () #5 0x100021dc in main () The program seems to loop in scheduleWaitThread, toggling the HeapProfTimer endlessly and nothing useful happens. Any idea what could be wrong, or how I could tackle debugging this problem. The native build of the same program with same compiler version (HEAD) works well. Under what condition is scheduleWaitThread supposed to return? How can I enable source debugging for RTS files? I should note that this is a big-endian target (PPC) and I have seen trouble with certain fields being wrongly swapped in the past, but IIRC those resulted in crashes. Cheers and thanks, Gabor

3 2