- ghc-devs - Haskell.org

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

Re: [commit: ghc] master: Add OverloadedLists, allowing list syntax to be overloaded (3234a4a)
by Johan Tibell 14 Feb '13

14 Feb '13

Did we end up supporting a length hint so we can efficiently create e.g. vectors that need upfront allocation of the space before writing the elements? Or is the plan to do like we for String and have literals desugar to e.g. fromIntList# :: Int# -> Ptr Int# -> [Int] intList# :: Ptr Int# intList# = [1,2,3,4]# myliteral = fromList (fromIntList# 4 intList#) On Thu, Feb 14, 2013 at 6:56 AM, Simon Peyton Jones <simonpj(a)microsoft.com>wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > > http://hackage.haskell.org/trac/ghc/changeset/3234a4ade7204c4206831b4c1dc4a… > > >--------------------------------------------------------------- > > 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(-) > > > Diff suppressed because of size. To see it, use: > > git show 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

Today's validate failures
by Simon Marlow 14 Feb '13

14 Feb '13

On x86_64/Linux: Unexpected passes: perf/should_run T149 (normal) Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) simplCore/should_compile T3717 [stderr mismatch] (optasm) simplCore/should_compile T3772 [bad stdout] (normal) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile T4930 [stderr mismatch] (optasm) simplCore/should_compile T7360 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm)

3 2

Why write out-of-line PrimOps in Cmm?
by Alexander Kjeldaas 14 Feb '13

14 Feb '13

I was looking at the eventlog code, and I wanted to move processing of a full eventlog buffer into Haskell, instead of the now fixed behavior of writing the data to a file. To do this, I though that having a haskell process blocked on an MVar, or Chan would be nice, and then some way to signal the process. But the low-level PrimOps for MVars, takeMVar, tryTakeMVar etc are in PrimOps.cmm and I don't know how to call them from the RTS. This lead me to question what the point of out-of-line PrimOps in PrimOps.cmm is. I don't think the commentary covers this. http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps So why aren't all the stuff in PrimOps.cmm just "ccall" wrappers around C implementations? Wouldn't that in general be more flexible for the RTS? Alexander

2 1

Merging polykinded typeable
by José Pedro Magalhães 14 Feb '13

14 Feb '13

Hi Simon, I think the polykinded stuff is now ready to merge. A few issues remain: 1) dynamic004 fails when run without optimisation (it times out). This is potentially worrying. It's doing a comparison of the typeReps of nested lists, up to 1000 nested lists. This worked fine before with -O0, but not anymore. With -O1 it works fine, though. Hopefully it's ok to just run this test with optimisation only, and assume that no one should expect great performance of Typeable on huge types with -O0... 2) With -XAutoDeriveTypeable, if you also derive Typeable instances in the module, you'll get a "duplicate instances" error. I think you'd rather have this be a warning, so that the semantics if -XAutoDeriveTypeable would be "derive Typeable for types/classes for which Typeable is not yet derived", instead of "derive Typeable for all types/classes declared". But I found this a bit tricky to check for, and as such haven't implemented it yet. I can point you to the place in the code where this is happening. 3) I don't know where to put `data Proxy t = Proxy`. I kind of need it for defining things in the library, but it doesn't need to be exported to the user, as we now have `typeRep :: forall proxy. proxy a -> TypeRep`. I do export it from Data.Typeable.Internal, because I want to use it in Data.Typeable, but I don't re-export it from Data.Typeable. This is, in principle, all fine, but I think that the Proxy datatype is so commonplace that it should probably be defined in GHC somewhere, so that it doesn't start showing up repeated in all sorts of libraries. Perhaps we can just put it in GHC.Exts? Either way, I'd like to merge this to the master branch now, and deal with the issues above after that. This is because it's tiresome to keep my branch up-to-date with master, and I don't think the remaining issues are blocking, or will affect the stability of the master branch. Regarding documentation, I've updated the user's guide to mention the new behaviour of Typeable, the fact that you can't define instances by hand, and the new flags (-XAutoDeriveTypeable and -fwarn-typeable-instances). I've written a blog post in the past about the new features ( http://hauptwerk.blogspot.co.uk/2012/11/coming-soon-in-ghc-head-poly-kinded…) and I'll write another one about how to make sure your old Typeable code works in the new version. If you want to have a look at the code before merging, let me know, and I'll update the new-typeable branch. (I've stopped working on that branch, and now I have a local branch ready for merging with a single commit to master). Cheers, Pedro

2 3

Vector primops sizes
by Michael Baikov 14 Feb '13

14 Feb '13

Recently merged vector primops support only 16 bytes operands - Int32 x 4, Double x 2 and so on. Current AVX instructions support 256 bit operands and with simple cut'n'paste work it's possible to support at least Double x 4 operands. I made those changes and GHC generates (using llvm) proper AVX code using ymm registers. Also it might make sense to support primops for vector types larger than any currently supported primitive types - I have those changes in my branch as well and llvm generates pretty good code as well - those changes might be useful to provide access for llvm shufflevector instruction or writing high performance processing of large vectors - with less potential overhead. Do we want to support larger vectors directly or ghc should be made smart enough to fuse operations with vector primops performed in parallel into larger vectors/registers for llvm? Do we want to provide access to llvm shufflevector instruction?

5 7

[PATCH] base: use --target as target, not uname
by Sergei Trofimovich 14 Feb '13

14 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- configure.ac | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b679520..7553a7a 100644 --- a/configure.ac +++ b/configure.ac @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) +AC_CANONICAL_BUILD +AC_CANONICAL_HOST +AC_CANONICAL_TARGET + AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() -case `uname -s` in - MINGW*|CYGWIN*) +AC_MSG_CHECKING(for WINDOWS platform) +case $host in + *mingw32*|*cygwin*) WINDOWS=YES;; *) WINDOWS=NO;; esac +AC_MSG_RESULT($WINDOWS) # do we have long longs? AC_CHECK_TYPES([long long]) -- 1.8.1.2

3 4

[PATCH] Fix comment to use correct option name
by shelarcy 14 Feb '13

14 Feb '13

Hello, Source Code Comments decribe wrong (old) option name in two place. I made patch to fix that. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

2 1

[PATCH] hsc2hs: use configuration of current compiler, not built
by Sergei Trofimovich 13 Feb '13

13 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 of such kind: "/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.0 -package containers-0.5.0.0 -package directory-1.2.0.0 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/Paths_hsc2hs.o utils/hsc2hs/dist/build/Main.o: In function `s4cN_info': (.text+0x182): undefined reference to `GetModuleFileNameW' Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- Main.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Main.hs b/Main.hs index 30b3a2d..5309179 100644 --- a/Main.hs +++ b/Main.hs @@ -11,7 +11,7 @@ -- See the documentation in the Users' Guide for more details. #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) -#include "../../includes/ghcconfig.h" +#include "ghcconfig.h" #endif import Control.Monad ( liftM, forM_ ) -- 1.8.1.1

2 2