October 2014 - ghc-devs

optimizing StgPtr allocate (Capability *cap, W_ n)
by Bulat Ziganshin 14 Oct '14

14 Oct '14

Hello, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rt… if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { .... } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } .... } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

FW: optimizing StgPtr allocate (Capability *cap, W_ n)
by Simon Peyton Jones 14 Oct '14

14 Oct '14

Simon, did you see this? Simon -----Original Message----- From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Bulat Ziganshin Sent: 14 October 2014 18:09 To: glasgow-haskell-users(a)haskell.org Subject: optimizing StgPtr allocate (Capability *cap, W_ n) Hello Glasgow-haskell-users, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rt… if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { .... } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } .... } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Broken build: 32-bit FreeBSD, SmartOS, Solaris
by Páli Gábor János 14 Oct '14

14 Oct '14

Hello there, Looks one of the recent commits broke the x86 builds on multiple platforms [1][2][3]. The common error message basically is as follows: rts/Linker.c: In function 'mkOc': rts/Linker.c:2372:6: error: 'ObjectCode' has no member named 'symbol_extras' Please fix it! Note that the x86_64 counterparts of the affected builders completed their builds fine -- except for Solaris, but that has been broken already for a long time (relatively). [1] http://haskell.inf.elte.hu/builders/smartos-x86-head/144/10.html [2] http://haskell.inf.elte.hu/builders/freebsd-i386-head/403/10.html [3] http://haskell.inf.elte.hu/builders/solaris-x86-head/191/10.html

6 10

Building ghc on Windows with msys2
by Gintautas Miliauskas 13 Oct '14

13 Oct '14

Hello, I have been messing around a little bit with building GHC from source on Windows, and found the msys2 wikipage <https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2> quite useful, but somewhat outdated. Quite a few steps in those instructions are no longer necessary and can be omitted. I am working on cleaning up that wikipage right now and should be done in a day or two. I've found a recent email <http://www.haskell.org/pipermail/ghc-devs/2014-September/006251.html> in the middle of updating the wikipage about other people planning to do the same, so I thought I'd shoot an email to make sure that work is not being duplicated. msys2 seems to be in good shape and should probably be promoted to the primary suggested method to build ghc on Windows. Let's look into that once the new build instructions have been proofread and verified. Best regards, -- Gintautas Miliauskas

11 35

Errors building GHC on iOS with LLVM >= 3.4
by Murray Campbell 13 Oct '14

13 Oct '14

Hi, I am trying to help solve #9125 in which an ARM build creates binaries that mangle Float values. After a great deal of help from rwbarton (detailed in the comments) it would appear that the problem is actually in LLVM 3.0. (v3.0 is virtually insisted upon in the iOS build instructions) Building GHC 7.8.3 for the iOS simulator with LLVM 3.4 produces a compiler that creates well behaved binaries. Unfortunately, building the device version fails with several warnings along the lines of: /var/folders/02/0mv6cz6505x2xhzlr279k2340000gp/T/ghc5244_0/ghc5244_6-armv7s.s:2944:2: warning: deprecated since v7, use 'dmb' mcr p15, #0, r7, c7, c10, #5 and: libraries/ghc-prim/cbits/popcnt.c:76:38: warning: shift count >= width of type [-Wshift-count-overflow] popcount_tab[(unsigned char)(x >> 32)] + ^ ~~ before bailing with /var/folders/02/0mv6cz6505x2xhzlr279k2340000gp/T/ghc6860_0/ghc6860_6-armv7.s:3916:2: error: out of range pc-relative fixup value vldr d8, LCPI70_0 ^ /var/folders/02/0mv6cz6505x2xhzlr279k2340000gp/T/ghc6860_0/ghc6860_6-armv7s.s:3916:2: error: out of range pc-relative fixup value vldr d8, LCPI70_0 ^ Next I tried to build HEAD (plus phabricator D208) with LLVM 3.4 but got the same error. Various adventures with LLVM 3.5 ended with the same error. I am trying to educate myself in ARM assembly but in the meantime does this ring any bells for anyone? I don't see anything on the trac. Thanks, Murray Campbell

2 3

RE: ExtraCommas
by Simon Peyton Jones 13 Oct '14

13 Oct '14

| What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where No. I'm proposing this. Insetad of data HsRecFields id = HsRecFields { rec_flds :: [HsRecField id arg], rec_dotdot :: Maybe Int have this: data HsRecFields id = HsRecFields { rec_flds :: HsCommaList (HsRecField id arg), rec_dotdot :: Maybe Int data HsCommaList a = Empty | ExtraComma (HsCommaList a) | Cons a (HsCommaList a) So that HsCommaList a is very like [a] but can express precisely where the extra commas appear. Now adapt the parser to produce a (HsCommaList (HsRecField RdrName (LHsExpr RdrName))), rather than a list of those things. The renamer then complains if it finds any ExtraComma constructors, unless the -XExtraCommas is specified. Does that help? Simon | -----Original Message----- | From: Alexander Berntsen [mailto:alexander@plaimi.net] | Sent: 23 September 2014 10:40 | To: Simon Peyton Jones | Subject: Re: ExtraCommas | | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA256 | | On 23/09/14 11:28, Simon Peyton Jones wrote: | > My advice was only: parse commas *always* as if they were part of | the | > language. (So the parser has no conditinoals.) Reject them later (in | > the renamer) if the language extension is not enabled. | I don't understand this. From my limited understanding commas are | lexed, and then I can, in the parser, pattern match on things. Here's | a very specific example, record field update/construction: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbinds1 { $1 } | | {- empty -} { ([], False) } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of (flds, dd) -> | ($1 : flds, dd) } | | fbind { ([$1], False) } | | '..' { ([], True) } | | What's happening here is that fbinds uses a helper fbinds1, to capture | both fbinds1 & emptys. So to add support for leading/trailing commas, | what I did is simply pattern match on them: | | fbinds :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : ',' fbinds1 { $2 } | | fbinds1 { $1 } | | fbinds1 :: { ([HsRecField RdrName (LHsExpr RdrName)], Bool) } | : fbind ',' fbinds1 { case $3 of | (flds, dd) -> ($1 : flds, dd) | } | | fbind { ([$1], False) } | | '..' { ([], True) } | | {- empty -} { ([], False) } | | You can observe that I am now using fbinds to capture ',' fbinds1, and | have moved the empty match to fbinds1 itself. | | This is the general pattern I have used for all of my patches so far. | | | What I think you are proposing is to capture commas in a different way | altogether before this stage, and I do not understand how or where | this is meant to happen. And it also sounds like your suggestion will | mean I need to handle the case where extra commas are *not* supposed | to be handwaved, like tuples. So please elaborate, if you can. | | > Happy to talk. I'm simonpj0 on skype. | Do you happen to use any non-proprietary tool or at least protocol? | - -- | Alexander | alexander(a)plaimi.net | https://secure.plaimi.net/~alexander | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v2 | Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ | | iF4EAREIAAYFAlQhP9sACgkQRtClrXBQc7U0+gD/TvT+9iVA6JqiopTfeYEc7NU2 | USD2bf+bKwhy9MNUjssA/3YUjA3PVYRpw1RFoRQF15zBFF6WDH5PQbS/8/5q7h+P | =saJc | -----END PGP SIGNATURE-----

3 2

Re: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions
by Alan & Kim Zimmerman 13 Oct '14

13 Oct '14

Ok, will do. An integer can potentially have any number of leading zeros, and I will have to check what escaping exists in the others. On Mon, Oct 13, 2014 at 11:33 AM, GHC <ghc-devs(a)haskell.org> wrote: > #9628: Add Annotations to the AST to simplify source to source conversions > -------------------------------------+------------------------------------- > Reporter: alanz | Owner: alanz > Type: feature | Status: new > request | Milestone: > Priority: normal | Version: 7.9 > Component: Compiler | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: | Related Tickets: > None/Unknown | > Test Case: | > Blocking: | > Differential Revisions: D297 | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > I suggest doing so only if the two can differ. In the case of `String` > there can be string gaps, thus > {{{ > foo :: String > foo = "blah blah\ > \more blah blah\ > \and more" > }}} > and I guess you want to have all that layout reproduced. Fine. But for > integers like `3234242329423`, I don't see how the displayed form could > differ. > > For `Words` perhaps there is binary/hex forms? > > Regardless, I'm not against this, but very keen that the reasons for > keeping the two are documented on a per-literal basis, as I have begun to > do above. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9628#comment:29> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

GHC HEAD breakage by pthread_setname_np usage.
by Karel Gardas 13 Oct '14

13 Oct '14

Hello Simon, I'm sorry to disturb you, but your recent patch: commit 674c631ea111233daa929ef63500d75ba0db8858 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Fri Oct 10 14:26:19 2014 +0100 Name worker threads using pthread_setname_np This helps identify threads in gdb particularly in processes with a lot of threads. breaks build on FreeBSD and Solaris at least. The problem is that pthread_setname_np is GNU extension and so far I've seen it just in linux using glibc >=2.12, modern NetBSD and modern QNX. Builds on Solaris and FreeBSD result in unresolved symbol failure. Two examples showing this are here: http://haskell.inf.elte.hu/builders/smartos-x86-head/147/10.html http://haskell.inf.elte.hu/builders/freebsd-amd64-head/411/10.html The problem is that I cannot simply #ifdef usage of this since it's using `name' parameter of the createOSThread function and if I #ifdef this, then the compiler emits obvious warning: rts/posix/OSThreads.c: In function ‘createOSThread’: rts/posix/OSThreads.c:132:40: warning: unused parameter ‘name’ which is probably going to break validate build which builds with -Werror. Perhaps if pthread_setname_np is not available on the target platform we can define it ourself (as empty macro or inline function doing nothing?) and use that, but in this case we would probably need proper configure check for the presence of this function. As rts is your domain, I'm just writing this in a hope that you will either revert the patch for now or solve it in a way you like. Thanks! Karel

2 1

RE: Building ghc on Windows with msys2
by Tamar Christina 13 Oct '14

13 Oct '14

Hi Gintautas, This seems like a good idea to me. I was also wondering would it be a good idea to have configure also handle cabal/happy/alex in a similar way? It would be another step you don't manually have to do and would make it easier to insure that the right versions are installed. Regards, Tamar ------------------------------ From: Gintautas Miliauskas <gintautas(a)miliauskas.lt> Sent: ‎13/‎10/‎2014 00:06 To: kyra <kyrab(a)mail.ru> Cc: ghc-devs(a)haskell.org Subject: Re: Building ghc on Windows with msys2 > However, overall (not GHC use cases) gcc 4.9.1 still looks more buggy on > Windows than 4.8.3. 'Mingw-builds' project (which is now a part of > mingw-w64 project and is considered to be an "official" mingw-w64 gcc > distribution and is maintained by a man close to Msys2 project) has very > nice and complete build of 4.8.3 (64-bit build, for example, is here: > http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting% > 20Win64/Personal%20Builds/mingw-builds/4.8.3/threads-posix/seh/). > I am looking into migrating ghc to the newer gcc package linked above. There is also the associated question of what to do with ghc-tarballs. Here's an idea: how about downloading the mingw package directly from sourceforge at configure time with curl/wget? That should work pretty well. I see two potential issues: 1. URL stability. The sourceforge repo is not in our control and files in it could go away any time. The repo seems stable though, with some files from 2011. If we're concerned about this, copying the file to a domain under our control should not be a problem. I did not get any responses about who to contact about that though... 2. Download failing due to internet connectivity issues or missing proxy configuration. This could easily be addressed by printing a message with a URL and a filesystem location to put the file in the case that the download fails. If there are no objections, I'll proceed with whipping up a patch. -- Gintautas Miliauskas

1 0

Problems adding a custom section to a Windows binary
by Gintautas Miliauskas 12 Oct '14

12 Oct '14

This is slightly offtopic, but maybe some of the Windows folks know an answer to this question. I've been working on #9686 <https://ghc.haskell.org/trac/ghc/ticket/9686>, but have been blocked by Windows rejecting all my attempts to add a custom section to a binary withthe error "bash: ./c.exe: cannot execute binary file: Exec format error". I'm not sure if this is a gcc/binutils bug or not (the exact same commands with the same tools work fine on Linux binaries). I have filed http://sourceforge.net/p/mingw/bugs/2239 and https://sourceware.org/bugzilla/show_bug.cgi?id=17466 to see what the developers say, but have not gotten a response yet. Perhaps someone here knows what's going on? -- Gintautas Miliauskas

3 2