August 2017 - ghc-devs

Limited availability next week
by Ben Gamari 02 Aug '17

02 Aug '17

Hello everyone, I will be travelling starting tomorrow through next week. During this time I'll still try to check in on things once a day to make sure nothing is burning down. However, I will be a bit less available. Still feel free to ping me via email or IRC, however. I'll try to get back to you. Cheers, - Ben

1 0

GHC release timing and future build infrastructure
by Ben Gamari 02 Aug '17

02 Aug '17

Hello everyone, I just posted a pair of posts on the GHC blog [1,2] laying out some thoughts on the GHC release cycle timing [1] and how this relates to the in-progress Jenkins build infrastructure [2]. When you have a some time feel free to give them a read and comment (either here or on the Reddit thread [3]). Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule [2] https://ghc.haskell.org/trac/ghc/blog/jenkins-ci [3] https://www.reddit.com/r/haskell/comments/6qt0iv/ghc_blog_reflections_on_gh…

3 2

Occurrence info on binders and STG
by Gabor Greif 02 Aug '17

02 Aug '17

Hi devs! I just had a short exchange with Joachim, he sent me to this place. Can anybody explain how occurrence info is used in STG? Cheers and thanks, Gabor ---------- Forwarded message ---------- From: Joachim Breitner <mail(a)joachim-breitner.de> Date: Tue, 01 Aug 2017 10:47:48 -0400 Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders (b311096) To: Gabor Greif <ggreif(a)gmail.com> Hi, feel free to CC the mailing list on such questions. I often don’t know things perfectly either. Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif: > > Loosely related question: Very loosely :-) > - when doing STG Cse, the occurrence info is not updated when a > wild(card)-binder is used. Is there a recommended way to re-run > occ-analysis on STG? (I fear there is not.) I fear that too. It the occ info used past that stage? > - I noticed that "wild"-binders sometimes do not appear at their > binding site (after "of" and "{") in STG dumps. Dumping gets > suppressed when they are deemed dead. Should STG consider occ-info at > all? Good questions. I remember that Simon commented on that before, but I don’t remember where… > oachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 1

RE: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy (6a50466)
by Simon Peyton Jones 02 Aug '17

02 Aug '17

Joachim Aha! I think my comment on Phab is redundant. You are simply avoiding name capture, which is obviously right; you are not restricting the applicability of the transformation. Needless to say, a Note would help in due course. S | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 02 August 2017 04:07 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T14068: Avoid name capture in setJoinResTy | (6a50466) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T14068 | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha | skell.org%2Ftrac%2Fghc%2Fchangeset%2F6a5046684f93f1870663119b447fff6ba | eb7a7c4%2Fghc&data=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea476 | 9222b08d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724 | 00832017356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi | IsIkFOIjoiT3RoZXIifQ%3D%3D%7C- | 1&sdata=29Iajm6oTE3Zm%2Bdl5ocMav7MPw%2FniO9%2BVeuQm38qWXQ%3D&reserved= | 0 | | >--------------------------------------------------------------- | | commit 6a5046684f93f1870663119b447fff6baeb7a7c4 | Author: Joachim Breitner <mail(a)joachim-breitner.de> | Date: Tue Aug 1 22:48:26 2017 -0400 | | Avoid name capture in setJoinResTy | | | >--------------------------------------------------------------- | | 6a5046684f93f1870663119b447fff6baeb7a7c4 | compiler/types/Type.hs | 22 ++++++++++++++++------ | 1 file changed, 16 insertions(+), 6 deletions(-) | | diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index | 50a35b0..c69d4ff 100644 | --- a/compiler/types/Type.hs | +++ b/compiler/types/Type.hs | @@ -2445,11 +2445,21 @@ setJoinResTy :: Int -- Number of binders to | skip | -> Type -- New type | -- INVARIANT: If any of the first n binders are foralls, those tyvars | cannot | -- appear in the original result type. See isValidJoinPointType. | +-- | +-- When we set the return type under a forall, avoid capture! | setJoinResTy orig_ar new_res_ty orig_ty | - = go orig_ar orig_ty | + = go init_subst orig_ar orig_ty | where | - go 0 _ = new_res_ty | - go n ty | Just (arg_bndr, res_ty) <- splitPiTy_maybe ty | - = mkPiTy arg_bndr (go (n-1) res_ty) | - | otherwise | - = pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty) | + init_subst :: TCvSubst | + init_subst = mkEmptyTCvSubst (mkInScopeSet (tyCoVarsOfType | + new_res_ty)) | + | + go _ 0 _ = new_res_ty | + go subst n ty | + | Just (t, ty') <- splitForAllTy_maybe ty | + , let (subst', t') = substTyVarBndr subst t | + = mkForAllTy t' Inferred (go subst' (n-1) ty') | + | Just (arg_ty, ty') <- splitFunTy_maybe ty | + , let arg_ty' = substTy subst arg_ty | + = mkFunTy arg_ty' (go subst (n-1) ty') | + | otherwise | + = pprPanic "setJoinResTy" (ppr orig_ar <+> ppr orig_ty) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=04%7C01%7Csimonpj%40microsoft.com%7Cc45ce3f4deea4769222b0 | 8d4d953af74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363724008320 | 17356%7CUnknown%7CVW5rbm93bnx7IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO | IjoiT3RoZXIifQ%3D%3D%7C- | 1&sdata=7%2FAY0EcihvMkjGOHdYdpOog2Roahk0XD%2BunNg54pKFc%3D&reserved=0

1 0

dataToTag# documentation
by David Feuer 02 Aug '17

02 Aug '17

dataToTag# is documented as getting the tag number of an enumeration, which is perfectly reasonable because it's designed to support deriving Enum. But it *appears* to work also for non-enumeration datatypes: dataToTag# Nothing = 0# dataToTag# (Just 3) = 1# Does this actually always work? If so, should that be documented, or is there a realistic possibility that its behavior will change in the future? Additionally: the documentation for dataToTag# urges readers to use GHC.Base.getTag instead. But dataToTag# is exported from the "public" GHC.Exts, whereas getTag is not. Should we add getTag to GHC.Exts, or change the documentation for dataToTag#? David

2 1

code layout of cryptarithm1
by Joachim Breitner 01 Aug '17

01 Aug '17

Hi, if you look at https://perf.haskell.org/ghc/#graph/nofib/time/cryptarithm1 you see that it’s performance varies a lot, sometimes by 10%, between commits should have nothing to do with performance. But most (not all!) of the commits where the performance changes affect the runtime in some way. I conclude that there is something about the code layout that makes this program run faster or slower. If anyone here enjoys tracing and understanding such low-level issues: Here is a nice target to aim at. (I don’t… but I’d appreciate less noise from gipeda :-)) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

GHC 8.2 generated code faster than 8.0 but slower than 7.10
by Harendra Kumar 01 Aug '17

01 Aug '17

Unicode normalization library ( https://github.com/harendra-kumar/unicode-transforms) shows around 10% improvement with GHC 8.2.1 when compared to GHC 8.0.1, across most benchmarks. However, it is still somewhat slower when compared to GHC 7.10.3. Here are some results: GHC 7.10.3: benchmarking unicode-transforms-text/NFD/English time 4.823 ms (4.765 ms .. 4.902 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.46 ms (16.24 ms .. 16.78 ms) GHC 8.0.1 benchmarking unicode-transforms-text/NFD/English time 6.330 ms (6.232 ms .. 6.439 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 18.02 ms (17.77 ms .. 18.22 ms) GHC 8.2.1 benchmarking unicode-transforms-text/NFD/English time 5.659 ms (5.594 ms .. 5.740 ms) benchmarking unicode-transforms-text/NFD/Devanagari time 16.48 ms (16.30 ms .. 16.69 ms) This library has been optimized with an objective to match or better (in some cases it is better) the performance of the equivalent ICU C++ library (compare only decompose normalization). Some of the last hurdles to match the best case of C++ were in the code generated by GHC. Also, for GHC 7.10 LLVM generated code is significantly faster than GHC native, I have not yet tested LLVM backend with 8.2.1 so not sure if that too has improved correspondingly. I just wanted to share these results with the GHC devs. Thanks for all the good work. Also wondering which specific changes might have caused this improvement. Thanks, Harendra

2 2