- ghc-devs - Haskell.org

FW: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0)
by Simon Peyton Jones 24 Mar '14

24 Mar '14

Austin, this one looks like a bug waiting to happen, so let's merge if time. Simon -----Original Message----- From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of git(a)git.haskell.org Sent: 24 March 2014 10:27 To: ghc-commits(a)haskell.org Subject: [commit: ghc] master: Add missing kind-check for tcEqType on forall-types (74894e0) Repository : ssh://git@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/74894e0bc405247092e865b9541f5f18d… >--------------------------------------------------------------- commit 74894e0bc405247092e865b9541f5f18d26aa015 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Mar 21 15:24:49 2014 +0000 Add missing kind-check for tcEqType on forall-types This wasn't showing up as a bug, but it was definitely wrong. >--------------------------------------------------------------- 74894e0bc405247092e865b9541f5f18d26aa015 compiler/typecheck/TcType.lhs | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/compiler/typecheck/TcType.lhs b/compiler/typecheck/TcType.lhs index 9b58b4c..08c7a62 100644 --- a/compiler/typecheck/TcType.lhs +++ b/compiler/typecheck/TcType.lhs @@ -245,7 +245,6 @@ checking. It's attached to mutable type variables only. It's knot-tied back to Var.lhs. There is no reason in principle why Var.lhs shouldn't actually have the definition, but it "belongs" here. - Note [Signature skolems] ~~~~~~~~~~~~~~~~~~~~~~~~ Consider this @@ -1008,7 +1007,8 @@ tcEqType ty1 ty2 | Just t2' <- tcView t2 = go env t1 t2' go env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 == rnOccR env tv2 go _ (LitTy lit1) (LitTy lit2) = lit1 == lit2 - go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2 + go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2) + && go (rnBndr2 env tv1 + tv2) t1 t2 go env (AppTy s1 t1) (AppTy s2 t2) = go env s1 s2 && go env t1 t2 go env (FunTy s1 t1) (FunTy s2 t2) = go env s1 s2 && go env t1 t2 go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) && gos env ts1 ts2 @@ -1027,7 +1027,8 @@ pickyEqType ty1 ty2 init_env = mkRnEnv2 (mkInScopeSet (tyVarsOfType ty1 `unionVarSet` tyVarsOfType ty2)) go env (TyVarTy tv1) (TyVarTy tv2) = rnOccL env tv1 == rnOccR env tv2 go _ (LitTy lit1) (LitTy lit2) = lit1 == lit2 - go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go (rnBndr2 env tv1 tv2) t1 t2 + go env (ForAllTy tv1 t1) (ForAllTy tv2 t2) = go env (tyVarKind tv1) (tyVarKind tv2) + && go (rnBndr2 env tv1 + tv2) t1 t2 go env (AppTy s1 t1) (AppTy s2 t2) = go env s1 s2 && go env t1 t2 go env (FunTy s1 t1) (FunTy s2 t2) = go env s1 s2 && go env t1 t2 go env (TyConApp tc1 ts1) (TyConApp tc2 ts2) = (tc1 == tc2) && gos env ts1 ts2 _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

7.8.1 RC testsuite failures for 64bit unregisterised builds
by Jens Petersen 24 Mar '14

24 Mar '14

(changing Subject to "fork" this to a separate thread) On 23 March 2014 21:42, Peter Trommler <ptrommler(a)me.com> wrote: > On 23.03.2014, at 11:44, Jens Petersen <petersen(a)fedoraproject.org> wrote: > >> Speaking of ppc64: Do you see ticket #8849 too? > > Does it show up in the testsuite results too? > > Yes, in fact I noticed the error in test arith005 and extracted the small > test case > for #8849. > Okay I did a ppc64 build with the testsuite: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1731757 and reproduced #8849 and (probably) #8819 too. I say "probably" since my ppc64 testsuite results are littered with "Actual stderr output differs from expected:" warnings caused by: """ + +In file included from /usr/include/math.h:26:0: + 0, + from /builddir/build/BUILD/ghc-7.8.0.20140228/includes/Stg.h:65, + from /tmp/ghc25682_0/ghc25682_3.hc:3: + +/usr/include/features.h:148:3: + warning: #warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-Wcpp] + # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" + ^ """ I only see those on ppc64 so far. Perhaps there is some way to ignore those? In #8819 I reported test failures in an unregisterised compiler produced on > my x86_64 machine using an unregisterised ghc. Almost all arith tests > including arith005 > fail and I suspect it might be a data layout issue. I wonder if you can > reproduce > #8819 on ppc64. #8849 makes me think yes. I reproduced also on s390x: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1369051 including #8819 unfortunately !! So seems this happens on ppc64, s390x and x86_64 for unregisterised. I know "unregisterised" may be considered less supported these days but this seems quite serious and I hope it could still be fixed for 7.8.1. Jens

1 0

Re: [commit: ghc] ghc-7.8: add --with-ar and --with-ranlib configure parameters (05e160e)
by Gabor Greif 23 Mar '14

23 Mar '14

Committed as 61654e5 Cheers, Gabor On 3/23/14, Karel Gardas <karel.gardas(a)centrum.cz> wrote: > > Hi Gabor, > > indeed! I can just follow my intention to follow general logic of: > > --with-<cmd> -> @<cmd>Cmd@ > > but you are right RANLIB logic is a little bit more comlex in aclocal.m4 > so it uses different variables (REAL_RANLIB_CMD/RANLIB_CMD) than "usual" > RanlibCmd. > > So if you care about one useless AC_SUBST(RanlibCmd), please send the > patch or if you do have commit access just fix that. As I said, > intention was to follow usual logic although in this case > non-functional.... > > Thanks, > Karel > > On 03/23/14 09:35 PM, Gabor Greif wrote: >> Hi Karel, >> >> I am missing a use of @RanlibCmd@, is this intentional? >> >> Cheers, >> >> Gabor >> >> On 3/23/14, git(a)git.haskell.org<git(a)git.haskell.org> wrote: >>> Repository : ssh://git@git.haskell.org/ghc >>> >>> On branch : ghc-7.8 >>> Link : >>> http://ghc.haskell.org/trac/ghc/changeset/05e160e36527f6f36f997d7aa56f0cbe4… >>> >>>> --------------------------------------------------------------- >>> >>> commit 05e160e36527f6f36f997d7aa56f0cbe4cbb50a3 >>> Author: Karel Gardas<karel.gardas(a)centrum.cz> >>> Date: Sun Feb 9 21:58:05 2014 +0100 >>> >>> add --with-ar and --with-ranlib configure parameters >>> >>> Both --with-ar and --with-ranlib are usable on non-GNU/Linux >>> systems >>> where GNU tools are usually installed (or possible to install), but >>> not into standard location nor with standard name. Tested on >>> Solaris >>> 10. >>> >>> Signed-off-by: Austin Seipp<austin(a)well-typed.com> >>> (cherry picked from commit >>> ac24bf45258af701cdd67423d6107357f27bbedf) >>> >>> >>>> --------------------------------------------------------------- >>> >>> 05e160e36527f6f36f997d7aa56f0cbe4cbb50a3 >>> configure.ac | 15 +++++++++++++++ >>> mk/config.mk.in | 1 + >>> 2 files changed, 16 insertions(+) >>> >>> diff --git a/configure.ac b/configure.ac >>> index 1c58da0..d32fd20 100644 >>> --- a/configure.ac >>> +++ b/configure.ac >>> @@ -486,6 +486,21 @@ FP_ARG_WITH_PATH_GNU_PROG([NM], [nm], [nm]) >>> NmCmd="$NM" >>> AC_SUBST([NmCmd]) >>> >>> +dnl ** Which ar to use? >>> +dnl -------------------------------------------------------------- >>> +FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar]) >>> +ArCmd="$AR" >>> +fp_prog_ar="$AR" >>> +AC_SUBST([ArCmd]) >>> + >>> +dnl ** Which ranlib to use? >>> +dnl -------------------------------------------------------------- >>> +FP_ARG_WITH_PATH_GNU_PROG([RANLIB], [ranlib], [ranlib]) >>> +RanlibCmd="$RANLIB" >>> +RANLIB="$RanlibCmd" >>> +AC_SUBST([RanlibCmd]) >>> + >>> + >>> # Note: we may not have objdump on OS X, and we only need it on >>> Windows >>> (for DLL checks) >>> case $HostOS_CPP in >>> cygwin32|mingw32) >>> diff --git a/mk/config.mk.in b/mk/config.mk.in >>> index fef1fb8..7cc7aec 100644 >>> --- a/mk/config.mk.in >>> +++ b/mk/config.mk.in >>> @@ -661,6 +661,7 @@ DTRACE = @DtraceCmd@ >>> >>> LD = @LdCmd@ >>> NM = @NmCmd@ >>> +AR = @ArCmd@ >>> OBJDUMP = @ObjdumpCmd@ >>> >>> LLC = @LlcCmd@ >>> >>> _______________________________________________ >>> ghc-commits mailing list >>> ghc-commits(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-commits >>> >> > >

1 0

When iselExpr64 (CmmLit (CmmInt i _)) is used?
by Karel Gardas 23 Mar '14

23 Mar '14

Hello, I'm trying to resurrect SPARC NCG. I've switched it on and basically provided functions on which NCG has panic during the build, basically just 2 were missing so far (cut from git diff): +genCCall (PrimTarget MO_Touch) _ _ + = return $ nilOL + +iselExpr64 (CmmLit (CmmInt i _)) = do + (rlo, rhi) <- getNewRegPairNat II32 + let + half0 = fromIntegral (fromIntegral i :: Word32) + half1 = fromIntegral (fromIntegral (i `shiftR` 32) :: Word32) + code = toOL [ + SETHI (HI $ ImmInt half0) rlo, + OR False rlo (RIImm (LO $ ImmInt half0)) rlo, + SETHI (HI $ ImmInt half1) rhi, + OR False rhi (RIImm (LO $ ImmInt half1)) rhi + ] + return (ChildCode64 code rlo) Now, my ghc-stage2 badly fails and testsuite run with stage=1 reveals 1390 unexpected failures. Perhaps this is unrelated, but still I'd like to test that my iselExpr64 implementation above is correct. Is there any simple haskell code which makes this function in NCG run? I'm trying this: import GHC.Prim import GHC.Exts main = do let x = 18446744073709551615# --- 2^64-1 = 18446744073709551615 putStrLn (show $ I# x) return() I've had a hope that unboxed long int constant is what causes iselExpr64 being called, but generated assembly looks suspicious -- like it's not called so my idea was wrong here probably. Do you have any idea how to test this function and see its generated assembly? BTW: I hope I got the function semantics correct as a loading of 64bit constant/integer into a pair of 32bits registers... Thanks a lot! Karel

2 2

Re: [commit: packages/template-haskell] master: Make Pred a type synonym of Type (issue #7021) (57b662c)
by Johan Tibell 23 Mar '14

23 Mar '14

What's the right way to fix libraries (e.g. aeson) that break because classP was removed? On Mon, Feb 10, 2014 at 2:39 AM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/template-haskell > > On branch : master > Link : > http://git.haskell.org/packages/template-haskell.git/commitdiff/57b662c3efd… > > >--------------------------------------------------------------- > > commit 57b662c3efd8579595c8642fce2d4cd60ba4ec0b > Author: YoEight <yo.eight(a)gmail.com> > Date: Fri Jan 10 21:42:01 2014 +0100 > > Make Pred a type synonym of Type (issue #7021) > > In order to make any type as a Predicate in Template Haskell, as > allowed by ConstraintKinds > > Signed-off-by: Richard Eisenberg <eir(a)cis.upenn.edu> > > > >--------------------------------------------------------------- > > 57b662c3efd8579595c8642fce2d4cd60ba4ec0b > Language/Haskell/TH.hs | 7 +++---- > Language/Haskell/TH/Lib.hs | 21 ++++++++------------- > Language/Haskell/TH/Ppr.hs | 8 ++------ > Language/Haskell/TH/Syntax.hs | 6 ++---- > 4 files changed, 15 insertions(+), 27 deletions(-) > > diff --git a/Language/Haskell/TH.hs b/Language/Haskell/TH.hs > index 2ab19bd..e9765a9 100644 > --- a/Language/Haskell/TH.hs > +++ b/Language/Haskell/TH.hs > @@ -68,7 +68,7 @@ module Language.Haskell.TH( > -- ** Patterns > Pat(..), FieldExp, FieldPat, > -- ** Types > - Type(..), TyVarBndr(..), TyLit(..), Kind, Cxt, Pred(..), > Syntax.Role(..), > + Type(..), TyVarBndr(..), TyLit(..), Kind, Cxt, Pred, > Syntax.Role(..), > > -- * Library functions > -- ** Abbreviations > @@ -105,14 +105,14 @@ module Language.Haskell.TH( > bindS, letS, noBindS, parS, > > -- *** Types > - forallT, varT, conT, appT, arrowT, listT, tupleT, sigT, litT, > + forallT, varT, conT, appT, arrowT, equalityT, listT, tupleT, sigT, > litT, > promotedT, promotedTupleT, promotedNilT, promotedConsT, > -- **** Type literals > numTyLit, strTyLit, > -- **** Strictness > isStrict, notStrict, strictType, varStrictType, > -- **** Class Contexts > - cxt, classP, equalP, normalC, recC, infixC, forallC, > + cxt, normalC, recC, infixC, forallC, > > -- *** Kinds > varK, conK, tupleK, arrowK, listK, appK, starK, constraintK, > @@ -146,4 +146,3 @@ module Language.Haskell.TH( > import Language.Haskell.TH.Syntax as Syntax > import Language.Haskell.TH.Lib > import Language.Haskell.TH.Ppr > - > diff --git a/Language/Haskell/TH/Lib.hs b/Language/Haskell/TH/Lib.hs > index b7a88d6..17e794b 100644 > --- a/Language/Haskell/TH/Lib.hs > +++ b/Language/Haskell/TH/Lib.hs > @@ -466,19 +466,6 @@ tySynEqn lhs rhs = > cxt :: [PredQ] -> CxtQ > cxt = sequence > > -classP :: Name -> [TypeQ] -> PredQ > -classP cla tys > - = do > - tys1 <- sequence tys > - return (ClassP cla tys1) > - > -equalP :: TypeQ -> TypeQ -> PredQ > -equalP tleft tright > - = do > - tleft1 <- tleft > - tright1 <- tright > - return (EqualP tleft1 tright1) > - > normalC :: Name -> [StrictTypeQ] -> ConQ > normalC con strtys = liftM (NormalC con) $ sequence strtys > > @@ -536,6 +523,14 @@ sigT t k > t' <- t > return $ SigT t' k > > +equalityT :: TypeQ -> TypeQ -> TypeQ > +equalityT tleft tright > + = do > + tleft1 <- tleft > + tright1 <- tright > + let typ = AppT (AppT EqualityT tleft1) tright1 > + return typ > + > promotedT :: Name -> TypeQ > promotedT = return . PromotedT > > diff --git a/Language/Haskell/TH/Ppr.hs b/Language/Haskell/TH/Ppr.hs > index 2023f3a..e237066 100644 > --- a/Language/Haskell/TH/Ppr.hs > +++ b/Language/Haskell/TH/Ppr.hs > @@ -496,6 +496,8 @@ instance Ppr Type where > > pprTyApp :: (Type, [Type]) -> Doc > pprTyApp (ArrowT, [arg1,arg2]) = sep [pprFunArgType arg1 <+> text "->", > ppr arg2] > +pprTyApp (EqualityT, [arg1, arg2]) = > + sep [pprFunArgType arg1 <+> text "~", ppr arg2] > pprTyApp (ListT, [arg]) = brackets (ppr arg) > pprTyApp (TupleT n, args) > | length args == n = parens (sep (punctuate comma (map ppr args))) > @@ -540,11 +542,6 @@ pprCxt [t] = ppr t <+> text "=>" > pprCxt ts = parens (sep $ punctuate comma $ map ppr ts) <+> text "=>" > > ------------------------------ > -instance Ppr Pred where > - ppr (ClassP cla tys) = ppr cla <+> sep (map pprParendType tys) > - ppr (EqualP ty1 ty2) = pprFunArgType ty1 <+> char '~' <+> pprFunArgType > ty2 > - > ------------------------------- > instance Ppr Range where > ppr = brackets . pprRange > where pprRange :: Range -> Doc > @@ -569,4 +566,3 @@ hashParens d = text "(# " <> d <> text " #)" > > quoteParens :: Doc -> Doc > quoteParens d = text "'(" <> d <> text ")" > - > diff --git a/Language/Haskell/TH/Syntax.hs b/Language/Haskell/TH/Syntax.hs > index 3606f9d..17bb065 100644 > --- a/Language/Haskell/TH/Syntax.hs > +++ b/Language/Haskell/TH/Syntax.hs > @@ -1346,9 +1346,7 @@ data AnnTarget = ModuleAnnotation > > type Cxt = [Pred] -- ^ @(Eq a, Ord b)@ > > -data Pred = ClassP Name [Type] -- ^ @Eq (Int, a)@ > - | EqualP Type Type -- ^ @F a ~ Bool@ > - deriving( Show, Eq, Data, Typeable ) > +type Pred = Type > > data Strict = IsStrict | NotStrict | Unpacked > deriving( Show, Eq, Data, Typeable ) > @@ -1373,6 +1371,7 @@ data Type = ForallT [TyVarBndr] Cxt Type -- ^ > @forall \<vars\>. \<ctxt\> -> \<t > | TupleT Int -- ^ @(,), (,,), etc.@ > | UnboxedTupleT Int -- ^ @(#,#), (#,,#), etc.@ > | ArrowT -- ^ @->@ > + | EqualityT -- ^ @~@ > | ListT -- ^ @[]@ > | PromotedTupleT Int -- ^ @'(), '(,), '(,,), etc.@ > | PromotedNilT -- ^ @'[]@ > @@ -1453,4 +1452,3 @@ cmpEq _ = False > thenCmp :: Ordering -> Ordering -> Ordering > thenCmp EQ o2 = o2 > thenCmp o1 _ = o1 > - > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

5 7

ghc-7.8.1 RC2 ppc dyn linked executable segfaults
by Jens Petersen 23 Mar '14

23 Mar '14

> > http://www.haskell.org/ghc/dist/7.8.1-rc2/ >> >> > A test build on ppc completed but then the dyn executable sanity check > failed (not yet sure why): > http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1707922 > The ppc64 build looks okay, but ppc seems to have a problem with executables dyn linked to Haskell libs segfaulting. Is anyone able to reproduce this on Linux/ppc (32bit)? Debian? I don't have access yet to a ppc box to investigate further but I see the segfault for "ghc -dynamic Hello.hs; ./Hello" on ppc in the fedora buildsys. http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1459/1711459/build.l…"ghc -v -dynamic Foo.hs") [1] I guess I should file a bug anyway. I sent a heads-up mail to Gustavo too. Jens [1] full log is http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/1459/1711459/build.l…

2 4

HEADS-UP: new server-side validation git hook for submodule updates & call-for-help
by Herbert Valerio Riedel 23 Mar '14

23 Mar '14

Hello *, I've put in place a new server-side validation hook a few days ago, and since nobody seemed to have complained yet, I assume it didn't have any adverse effects so far :-) It will only be triggered when Git submodule references are touched by a commit; you can find some preliminary (but incomplete) documentation and a sample session triggering validation-failure on purpose at https://ghc.haskell.org/trac/ghc/ticket/8251#comment:4 (this will be turned into a proper wiki-page once #8251 is completed; there's some minor details wrt some corner cases that still need to be looked at) So, this mostly addresses the server-side requirements for migrating to a proper git-submodule set-up for ghc.git; The next steps, however, include taking care of the client-side work-flow for working with a fully "submoduled" ghc.git setup. Personally, I'm quite comfortable using direct git commands to manage such a construct, but I'm well aware not everyone is (as previous discussions here have shown). Also, as my time is rather limited, I'd like to ask interested parties to join in and help formulate the future client-side work-flow[1] and/or update (or rewrite) the 'sync-all' to provide a seamless or at least smooth transition for those GHC devs who want to keep using "sync-all" instead of using direct Git commands. [1]: There's some difference in how tracked upstream packages and GHC-HQ owned sub-repos are to be handled workflow-wise, to avoid ending up with a noisy ghc.git history. For instance, having ghc.git with submodules is not the same as having a huge monolithic ghc.git repository with all subrepos embedded. specifically, it might not be sensible to propagate *every* single subrepo-commit as a separate ghc.git submod-ref update, but rather in logical batches (N.B.: using submodules gives the additional ability to git bisect within subrepos instead of having to bisect always only at top-level). This is one example of things to discuss/consider when designing the new work-flow. Cheers, hvr

5 6

Was GHC 7.8 RC2 profiled-compiled?
by Alfredo Di Napoli 21 Mar '14

21 Mar '14

Evening guys, was GHC 7.8 RC2 released with profiling enabled? Trying to use TH yields: You can't use Template Haskell with a profiled compiler This message is spit out from ghc mod. Do you guys know if the plan was releasing the RC2 profile compiled or is just a flag forgotten to be disabled? Furthermore, do you know if is available a non-profiled version available for Mavericks ? Sorry if I'm just being stupid! Alfredo

1 1

Haddock strings in .hi files
by Mateusz Kowalczyk 21 Mar '14

21 Mar '14

Hi all, I saw https://ghc.haskell.org/trac/ghc/ticket/5467 pop up in my inbox and it reminded me of something I've been wondering for a while: why do we not store Haddock docstrings in the interface file? I think that if we did, we could do some great things: 1. Show docs in GHCi (I vaguely recall someone working on this ~1 year ago, does anyone have any info?) 2. Allow Haddock to work a lot faster: the big majority of time spent when creating documentation is actually spent by Haddock calling various GHC functions, such as type-checking the modules. Only a small amount of time is actually spent by Haddock on other tasks such as parsing or outputting the documentation. If we could simply get everything we need from the .hi files, we save ourselves a lot of time. 3. Allow Haddock to create partial documentation: a complaint I sometimes hear is if anything at all in the project doesn't type check, we don't get any documentation at all. I think that it'd be viable to generate only the documentation for the modules/functions that do type-check and perhaps skip type signatures for everything else. Points 1. and 2. are of clear benefit. Point 3. is a simple afterthought and thinking about it some more, I think that maybe it'd be possible to do this with what we have right now: is type-checking separate parts of the module supported? Can we retrieve documentation for the parts that don't type-check? I am asking for input on what people think. I am not familiar at all with what goes into the .hi file (and I can't find anything concrete! Am I missing some wiki page?) at all and why. At the very least, 1. should be easy to implement. It was suggested that I submit a proposal for this as part of GSoC, namely implementing 1. and 2.. I admit that having much faster documentation builds would be amazing and Edward K. and Carter S. seem to think that this is very do-able in the 3 month period that GSoC runs over. While I say all this, I have already submitted my proposal on a different topic. I am considering writing this up and submitting this as well but I am looking for some insight into the problem first. If there are any students around still looking for ideas, please do speak up if you want to snatch this. If there are people that are eager to mentor something like this then I suppose they should speak up too. Thanks! -- Mateusz K.

6 12

Possible refactoring for __stg_gc_fun in HeapStackCheck.cmm
by Horsng Junn 20 Mar '14

20 Mar '14

Hi list! This is my first mail to the list; please correct me if I made any mistakes. I’ve been studying GHC source code for studying’s sake, and think I’ve found a few problems in this function. Below comes the function in its current form: ———————————————————— __stg_gc_fun /* explicit stack */ { W_ size; W_ info; W_ type; info = %GET_FUN_INFO(UNTAG(R1)); // cache the size type = TO_W_(StgFunInfoExtra_fun_type(info)); if (type == ARG_GEN) { size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info)); } else { if (type == ARG_GEN_BIG) { #ifdef TABLES_NEXT_TO_CODE // bitmap field holds an offset size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) + %GET_ENTRY(UNTAG(R1)) /* ### */ ); #else size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) ); #endif } else { size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]); } } #ifdef NO_ARG_REGS // we don't have to save any registers away Sp_adj(-3); Sp(2) = R1; Sp(1) = size; Sp(0) = stg_gc_fun_info; jump stg_gc_noregs []; #else W_ type; type = TO_W_(StgFunInfoExtra_fun_type(info)); // cache the size if (type == ARG_GEN || type == ARG_GEN_BIG) { // regs already saved by the heap check code Sp_adj(-3); Sp(2) = R1; Sp(1) = size; Sp(0) = stg_gc_fun_info; // DEBUG_ONLY(foreign "C" debugBelch("stg_fun_gc_gen(ARG_GEN)");); jump stg_gc_noregs []; } else { jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live // jumps to stg_gc_noregs after saving stuff } #endif /* !NO_ARG_REGS */ } The problems I see: 1. “type” variable is declared and its value calculated twice, 2. if (type == ARG_GEN … check is needlessly done twice, 3. “size" value is calculated and then discarded in !NO_ARG_REGS, for types other than ARG_GEN or ARG_GEN_BIG, and 4. (this is a minor one) Sp_adj(-3) ~ jmup_stg_gc_noregs code is duplicated. I know they’re in separate #if branch but still... And my proposed fixes are: ———————————————————— __stg_gc_fun /* explicit stack */ { W_ size; W_ info; W_ type; info = %GET_FUN_INFO(UNTAG(R1)); // cache the size type = TO_W_(StgFunInfoExtra_fun_type(info)); if (type == ARG_GEN) { // regs already saved by the heap check code size = BITMAP_SIZE(StgFunInfoExtra_bitmap(info)); } else { if (type == ARG_GEN_BIG) { // regs already saved by the heap check code #ifdef TABLES_NEXT_TO_CODE // bitmap field holds an offset size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) + %GET_ENTRY(UNTAG(R1)) /* ### */ ); #else size = StgLargeBitmap_size( StgFunInfoExtra_bitmap(info) ); #endif } else { #ifdef NO_ARG_REGS // we don't have to save any registers away size = BITMAP_SIZE(W_[stg_arg_bitmaps + WDS(type)]); #else jump W_[stg_stack_save_entries + WDS(type)] [*]; // all regs live // jumps to stg_gc_noregs after saving stuff #endif } } Sp_adj(-3); Sp(2) = R1; Sp(1) = size; Sp(0) = stg_gc_fun_info; jump stg_gc_noregs []; } What do you guys think? Thanks, Horsng Junn

2 2