- ghc-devs - Haskell.org

Re: Heads-up: new parallel I/O manager merged
by Bill Tutt 17 Feb '13

17 Feb '13

Yes, it should. Here's the combined patch that just succeded in being built. Bill On Sat, Feb 16, 2013 at 11:26 AM, Andreas Voellmy <andreas.voellmy(a)gmail.com > wrote: > > > in rts/ThrIOManager.hs >> > > Sorry, this should have been rts/win32/ThrIOManager.c. >

1 0

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 16 Feb '13

16 Feb '13

On Wed, Feb 13, 2013 at 07:11:11PM -0800, David Terei wrote: > > +AC_DEFUN([FIND_LLVM_PROG],[ > + FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL([$1], [$2], [$3]) > + if test "$1" == ""; then > + GOOD_PATH=`echo $PATH | tr ':,;' ' '` Hmm. I don't think we'll ever have a $PATH containing a path like c:/..., but there could certainly be paths containing spaces. > + $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` This feels rather unpleasant to me. Is it likely that someone will have programs called llc-3.0 etc, but no llc? If not, I'd suggest that we just detect llc and they can override which llc gets used with a --with-llc flag if they want to. In fact, i think we should do that regardless. After all, we don't try searching for gcc-4.6 etc either. Thanks Ian

2 1

GHC failing to build due to errors in DPH?
by Iavor Diatchki 16 Feb '13

16 Feb '13

Hello, I am trying to build GHC head and get the following error: libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: Ambiguous occurrence `fromList' It could refer to either `Data.Array.Parallel.PArray.Reference.fromList', defined at libraries/dph/dph-lifted-base/Data/Array This is using the stage 2 compiler and, I am guessing, is due to an interaction with the overloaded lists extension. I just deleted dph completely, and used `sync-all get` to get a fresh copy, but I get the same error. It looks like the nightly builds are working, so am I doing something wrong? More generally, I don't really need DPH, so is there an easy way to disable building it? -Iavor

5 4

RE: GHC failing to build due to errors in DPH?
by Simon Peyton-Jones 16 Feb '13

16 Feb '13

Sorry about that... I don’t know haw my validate worked. Anyway all good. Simon From: Ian Lynagh Sent: ‎15‎ ‎February‎ ‎2013 ‎20‎:‎10 To: Iavor Diatchki CC: ghc-devs(a)haskell.org Subject: Re: GHC failing to build due to errors in DPH? On Fri, Feb 15, 2013 at 11:09:33AM -0800, Iavor Diatchki wrote: > > I am trying to build GHC head and get the following error: > > libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: > Ambiguous occurrence `fromList' > It could refer to either > `Data.Array.Parallel.PArray.Reference.fromList', > defined at > libraries/dph/dph-lifted-base/Data/Array I've just pushed a fix for this. Thanks Ian _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

RE: OverloadedLists
by Simon Peyton-Jones 16 Feb '13

16 Feb '13

| Finally I managed to build again (don't know what's wrong with my | system, I built on a virtual machine instead now), and the tests pass. I | attached the four patches, they were created with git diff --no-prefix, | and their name specifies the submodule they are to be applied to. I hope | it isn't to late to include them in 7.8. Should I publish them somewhere | else also, or is this fine? Great. It's done! Thanks for all your work on this. Would you like to update the wiki page? http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists You probably don't want to mention your repo any more; and please just check the rest to make sure it's accurate. I did quite a bit of refactoring, especially to the type checking of arithmetic sequences, which had lots of duplication; fixed the documentation which was out of date; fixed various error message changes in the main testsuite; and committed. Simon commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Feb 14 13:04:14 2013 +0000 Add OverloadedLists, allowing list syntax to be overloaded This work was all done by Achim Krause <achim.t.krause(a)gmail.com> George Giorgidze <giorgidze(a)gmail.com> Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> It allows list syntax, such as [a,b], [a..b] and so on, to be overloaded so that it works for a variety of types. The design is described here: http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists Eg. you can use it for maps, so that [(1,"foo"), (4,"bar")] :: Map Int String The main changes * The ExplicitList constructor of HsExpr gets witness field * Ditto ArithSeq constructor * Ditto the ListPat constructor of HsPat Everything else flows from this. compiler/deSugar/Check.lhs | 15 ++-- compiler/deSugar/Coverage.lhs | 16 +++- compiler/deSugar/DsArrows.lhs | 2 +- compiler/deSugar/DsExpr.lhs | 42 +++++++---- compiler/deSugar/DsMeta.hs | 7 +- compiler/deSugar/Match.lhs | 31 ++++++-- compiler/hsSyn/Convert.lhs | 6 +- compiler/hsSyn/HsExpr.lhs | 12 ++- compiler/hsSyn/HsPat.lhs | 12 ++- compiler/hsSyn/HsUtils.lhs | 6 +- compiler/main/DynFlags.hs | 2 + compiler/parser/Parser.y.pp | 12 ++-- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/prelude/PrelNames.lhs | 26 ++++++- compiler/prelude/TysWiredIn.lhs | 2 +- compiler/rename/RnEnv.lhs | 18 +++-- compiler/rename/RnExpr.lhs | 45 +++++++---- compiler/rename/RnPat.lhs | 21 ++++- compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- compiler/typecheck/TcHsType.lhs | 2 +- compiler/typecheck/TcPat.lhs | 14 +++- compiler/typecheck/TcRnDriver.lhs | 2 +- compiler/typecheck/TcRnTypes.lhs | 2 + compiler/utils/Outputable.lhs | 4 +- docs/users_guide/flags.xml | 7 ++ docs/users_guide/glasgow_exts.xml | 157 +++++++++++++++++++++++++++++++++++++ 27 files changed, 469 insertions(+), 139 deletions(-)

4 5

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 16 Feb '13

16 Feb '13

On Fri, Feb 15, 2013 at 07:21:54PM +0100, Karel Gardas wrote: > On 02/15/13 07:03 PM, Ian Lynagh wrote: > >>+ $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` > > > >This feels rather unpleasant to me. Is it likely that someone will have > >programs called llc-3.0 etc, but no llc? > > Yes, Ubuntu 12.04 LTS installs LLVM 3.0 package in a way that, the > package binaries are installed into /usr/lib/llvm-3.0 directory and > inside /usr/bin there are llc-3.0 and opt-3.0 links created linking > to ../lib/llvm-3.0/bin/{llc|opt}. > > So David is fixing real-world issue here. But if you install 'llvm' (rather than 'llvm-3.0') then you get a /usr/bin/llc Analogously, on ubuntu, if you install 'gcc' then you get /usr/bin/gcc, but if you install 'gcc-4.6' then you get /usr/bin/gcc-4.6; but we don't search for gcc-* executables. Thanks Ian

2 1

Re: [commit: ghc] simd: Fixup stack spills when generating AVX instructions. (b787b5d)
by David Terei 16 Feb '13

16 Feb '13

Do we have a longer term solution for this? I love the SIMD work, so please don't take this as a complaint, I agree with getting it done for now with the mangler and truth is it's doubtful we'll et around to adding TNTC support to LLVM anytime soon, so mangler is here to stay for now. BUT. I would like to see some thought about how in an ideal world with lots of free time to hack on GHC we'd kill the mangler. Do we know that plan for this patch? If so it may be nice to document it somewhere and perhaps create a trac ticket. On 14 February 2013 23:16, Geoffrey Mainland <gmainlan(a)microsoft.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : simd > > http://hackage.haskell.org/trac/ghc/changeset/b787b5d1e687fb28643cdd6a847cc… > >>--------------------------------------------------------------- > > commit b787b5d1e687fb28643cdd6a847ccc26bb014a79 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Sat Nov 26 12:45:23 2011 +0000 > > Fixup stack spills when generating AVX instructions. > > LLVM uses aligned AVX moves to spill values onto the stack, which requires > 32-bye aligned stacks. Since the stack in only 16-byte aligned, LLVM inserts > extra instructions that munge the stack pointer. This is very very bad for the > GHC calling convention, so we tell LLVM to assume the stack is 32-byte > aligned. This patch rewrites the spill instructions that LLVM generates so they > do not require an aligned stack. > >>--------------------------------------------------------------- > > compiler/llvmGen/LlvmMangler.hs | 38 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/compiler/llvmGen/LlvmMangler.hs b/compiler/llvmGen/LlvmMangler.hs > index 83a2be7..745dcc6 100644 > --- a/compiler/llvmGen/LlvmMangler.hs > +++ b/compiler/llvmGen/LlvmMangler.hs > @@ -20,6 +20,10 @@ import System.IO > import Data.List ( sortBy ) > import Data.Function ( on ) > > +#if x86_64_TARGET_ARCH > +#define REWRITE_AVX > +#endif > + > -- Magic Strings > secStmt, infoSec, newLine, textStmt, dataStmt, syntaxUnified :: B.ByteString > secStmt = B.pack "\t.section\t" > @@ -47,6 +51,7 @@ llvmFixupAsm dflags f1 f2 = {-# SCC "llvm_mangler" #-} do > w <- openBinaryFile f2 WriteMode > ss <- readSections r w > hClose r > + let fixed = (map rewriteAVX . fixTables) ss > let fixed = fixTables ss > mapM_ (writeSection w) fixed > hClose w > @@ -90,6 +95,39 @@ writeSection w (hdr, cts) = do > B.hPutStrLn w hdr > B.hPutStrLn w cts > > +#if REWRITE_AVX > +rewriteAVX :: Section -> Section > +rewriteAVX = rewriteVmovaps . rewriteVmovdqa > + > +rewriteVmovdqa :: Section -> Section > +rewriteVmovdqa = rewriteInstructions vmovdqa vmovdqu > + where > + vmovdqa, vmovdqu :: B.ByteString > + vmovdqa = B.pack "vmovdqa" > + vmovdqu = B.pack "vmovdqu" > + > +rewriteVmovap :: Section -> Section > +rewriteVmovap = rewriteInstructions vmovap vmovup > + where > + vmovap, vmovup :: B.ByteString > + vmovap = B.pack "vmovap" > + vmovup = B.pack "vmovup" > + > +rewriteInstructions :: B.ByteString -> B.ByteString -> Section -> Section > +rewriteInstructions matchBS replaceBS (hdr, cts) = > + (hdr, loop cts) > + where > + loop :: B.ByteString -> B.ByteString > + loop cts = > + case B.breakSubstring cts matchBS of > + (hd,tl) | B.null tl -> hd > + | otherwise -> hd `B.append` replaceBS `B.append` > + loop (B.drop (B.length matchBS) tl) > +#else /* !REWRITE_AVX */ > +rewriteAVX :: Section -> Section > +rewriteAVX = id > +#endif /* !REWRITE_SSE */ > + > -- | Reorder and convert sections so info tables end up next to the > -- code. Also does stack fixups. > fixTables :: [Section] -> [Section] > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Advice needed: programmatically generating primops?
by Geoffrey Mainland 15 Feb '13

15 Feb '13

Hi All, There is a huge amount of boilerplate involved in adding a full complement of vector primops to GHC. I would like to reduce this boilerplate by programmatically generating the vector primops. My plan is to add utils/genvecprimops and #include its output into primops.txt.pp. Does this sound reasonable? Any objections? While I'm at it, is there any related cleanup I could undertake? Thanks, Geoff

5 6

Re: takeOneMVar?
by Alexander Kjeldaas 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 8:54 AM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > Apologies for the kibitzing. > > If anyone, it's me proposing weird stuff :-) > > -- This will fail if the MVarGroup is not associated with the current > > process (if the MVarGroup's TSO is not the current TSO)! > > I'm not super keen about this requirement. What if I want to create an > MVarGroup > but pass it to another thread? > > Our emails crossed each other :-). As you can see, I think this is solvable. Alexander > Edward >

2 2

takeOneMVar?
by Alexander Kjeldaas 15 Feb '13

15 Feb '13

Hi, I ended up staring at the PrimOps.cmm file today, and porting tryPutMVar to C so it can be used from the RTS. During my staring, it occurred to me that it should be possible to implement a wait-on-multiple MVars with mostly no overhead. I am guessing that this would be desirable, but I am not sure. My rough idea is like this: -- wait for all MVars, return the value of one of them, and the corresponding index takeOneMVar :: [MVar a] -> IO (a, Int) This is implemented by this change: typedef struct StgMVarTSOQueue_ { StgHeader header; struct StgMVarTSOQueue_ *link; * // The group_head and group_link are used when a TSO is waiting on* * // multiple MVars. Multiple StgMVarTSOQueue objects* * // are created, one for each MVar, and they are linked using the* * // group_link pointer. group_head always points to the first* * // element. The tso pointer will always be the same in this case.* * // The group head acts as a synchronization element for the whole group.* * // When the group head lock is acquired, the owner can invalidate the group* * struct StgMVarTSOQueue *group_head;* * struct StgMVarTSOQueue *group_link;* struct StgTSO_ *tso; } StgMVarTSOQueue; Now, whenever a TSO should be woken up by the MVar code, if ... putMVar(...) { ... queue = mvar->queue... loop: if (end_of_queue(queue) { return 0; } * if (marked_as_invalid(queue) { // invalid = (queue->group_head == NULL) for example* * queue = queue->link;* * goto loop;* * }* * if (queue->group_head != queue) {* * // Try to win race to wake up the TSO with *our* MVar. * * won = TryLock(queue->group_head);* * if (!won) {* * // ignore this queue element for now, we can't get the lock, * * // and it will be marked_as_invalid at some point in the future anyways.* * queue = queue->link;* * goto loop; // try next* * }* * if (won) {* * for all in group, mark them as "invalid"* * Unlock(queue->group_head);* * goto wake_up_tso;* * } else { * * // Did not win* * goto loop;* * }* } else { ..what is currently done.. wake_up_tso: ... do wake up Alexander

2 3