March 2017 - ghc-devs

Travis again over time
by Joachim Breitner 18 Mar '17

18 Mar '17

Hi, I just noticed that travis again fails to build master, and did so for four days. The build logs only get sent to the committer, so if the first person breaking the build does not react, then all following commiters (who likely did obviously benign changes) will likely ignore any failures, (even if they break some of the test cases) and we have a broken-window effect. I wonder if we should configure travis to send build error messags to, for example, ghc-commits? Anyways, build time has increased and reached the (recently raised) time limit of 70 minutes. I fail to identify an obviously offending commit. Last working commit (which, by sheer luck, passed the time limit) was https://github.com/ghc/ghc/commit/fc6c222b90e68fed74a6bee6f087f47bf31f21c6 It looks that much of the time increase is due to enabling split sections by default: https://travis-ci.org/ghc/ghc/builds/198293519 I’ll see if that helps. 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

4 6

Adding a module
by Simon Peyton Jones 16 Mar '17

16 Mar '17

If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits If you add a module to GHC, I know you need to extend ghc.cabal.in. But also ghc.mk? Otherwise I get hits /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Extra modules: CoreOpt make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Is it necessary to have two places to extend? Simon

4 3

Bounding I/O imprecision
by David Feuer 16 Mar '17

16 Mar '17

Thinking more about this I/O demand analysis thing. I don't think it's possible for the compiler to decide for itself what to fuzz, but a user might know very well. Given m >>= f there are really two sensible approaches: 1. Want to ensure m is executed even if the action produced by f will diverge. 2. Not care whether m is executed if the compound action will ultimately diverge. Our current I/O hack mixes these two in an unprincipled way. The second approach, not caring, is certainly the most natural for GHC's implementation of I/O: we're defining a function from the real world to a new real world and a value; the function is partial and we don't care about the details. This is fairly clearly the right way to handle strict ST: if we don't get a result at the end, we don't get anything useful and don't care what actions get dropped. The first approach seems to offer a better way to explain I/O and evaluation to users, ensuring that evaluation is only performed to the extent necessary for execution. This is partially supported by the I/O hack when it triggers. But it doesn't always, and it's not entirely clear if we can make do so. Still no real conclusions here; just exploring the problem more. David FeuerWell-Typed, LLP

1 0

LLVM calling convention for AVX2 and AVX512 registers
by Edward Kmett 15 Mar '17

15 Mar '17

Back around 2013, Geoff raised a discussion about fixing up the GHC ABI so that the LLVM calling convention could pass 256 bit vector types in YMM (and, i suppose now 512 bit vector types in ZMM). As I recall, this was blocked by some short term concerns about which LLVM release was imminent or what have you. Four years on, the exact same sort of arguments could be dredged up, but yet in the meantime nobody is really using those types for anything. This still creates a pain point around trying to use these wide types today. Spilling rather than passing them in registers adds a LOT of overhead to any attempt to use them that virtually erases any benefit to having them in the first place. I started experimenting with writing some custom primops directly in llvm so I could do meaningful amounts of work with our SIMD vector types by just banging out the code that we can't write in haskell directly using llvm assembly, and hoping I could trick LLVM to do link time optimization to perhaps inline it, but I'm basically dead in the water over the overhead of our current calling convention, before I even start, it seems, as if we're spilling them there is no way that inlining / LTO could hope to figure out what we're doing out as part of the spill to erase that call entirely. It is rather frustrating that I can't even cheat. =/ What do we need to do to finally fix this? -Edward

7 25

RE: Another strictness analysis wrinkle
by David Feuer 15 Mar '17

15 Mar '17

Actually, I just had a thought. What if we ran ST computations with a different state token type? Say, State# FakeWorld? Would that let them escape the hack? David FeuerWell-Typed, LLP -------- Original message --------From: David Feuer <david(a)well-typed.com> Date: 3/15/17 6:38 AM (GMT-05:00) To: GHC developers <ghc-devs(a)haskell.org> Subject: Another strictness analysis wrinkle I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP

1 0

Another strictness analysis wrinkle
by David Feuer 15 Mar '17

15 Mar '17

I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh. David FeuerWell-Typed, LLP

1 0

RE: [GHC] #13413: GHC HEAD panic: collectNBinders
by Simon Peyton Jones 15 Mar '17

15 Mar '17

I know what is going on here. I'm in a meeting all day, but I hope to fix tomorrow. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 11 March 2017 20:12 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #13413: GHC HEAD panic: collectNBinders | | #13413: GHC HEAD panic: collectNBinders | -------------------------------------+---------------------------------- | -------------------------------------+--- | Reporter: RyanGlScott | Owner: (none) | Type: bug | Status: new | Priority: highest | Milestone: 8.2.1 | Component: Compiler | Version: 8.1 | Keywords: JoinPoints | Operating System: | Unknown/Multiple | Architecture: | Type of failure: GHC rejects | Unknown/Multiple | valid program | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | -------------------------------------+---------------------------------- | -------------------------------------+--- | `repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this | issue. Trying to build it leads to several `collectNBinders` panics is | various modules. You can reproduce this by compiling this module: | | {{{#!hs | {-# LANGUAGE BangPatterns #-} | {-# LANGUAGE MagicHash #-} | module Data.Repa.Eval.Generic.Seq.Chunked where | | import GHC.Exts (Int#, (+#), (*#), (>=#)) | | ------------------------------------------------------------------------ | ------- | -- | Fill a block in a rank-2 array, sequentially. | -- | -- * Blockwise filling can be more cache-efficient than linear filling | for | -- rank-2 arrays. | -- | -- * The block is filled in row major order from top to bottom. | -- | fillBlock2 | :: (Int# -> a -> IO ()) -- ^ Update function to write into | result buffer. | -> (Int# -> Int# -> a) -- ^ Function to get the value at an (x, | y) index. | -> Int# -- ^ Width of the whole array. | -> Int# -- ^ x0 lower left corner of block to | fill. | -> Int# -- ^ y0 | -> Int# -- ^ w0 width of block to fill | -> Int# -- ^ h0 height of block to fill | -> IO () | | fillBlock2 | write getElem | !imageWidth !x0 !y0 !w0 h0 | | = do fillBlock y0 ix0 | where !x1 = x0 +# w0 | !y1 = y0 +# h0 | !ix0 = x0 +# (y0 *# imageWidth) | | {-# INLINE fillBlock #-} | fillBlock !y !ix | | 1# <- y >=# y1 = return () | | otherwise | = do fillLine1 x0 ix | fillBlock (y +# 1#) (ix +# imageWidth) | | where {-# INLINE fillLine1 #-} | fillLine1 !x !ix' | | 1# <- x >=# x1 = return () | | otherwise | = do write ix' (getElem x y) | fillLine1 (x +# 1#) (ix' +# 1#) | | {-# INLINE [0] fillBlock2 #-} | }}} | | This compiles on GHC 8.0.2, but on GHC HEAD: | | {{{ | $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs | [1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o ) | ghc-stage2: panic! (the 'impossible' happened) | (GHC version 8.1.20170201 for x86_64-unknown-linux): | collectNBinders | 2 | Call stack: | CallStack (from HasCallStack): | prettyCurrentCallStack, called at | compiler/utils/Outputable.hs:1179:58 in ghc:Outputable | callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in | ghc:Outputable | pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in | ghc:CoreSyn }}} | | Interestingly, compiling this triggers the panic at any optimization | level, but loading the module into GHCi does not cause it to panic. | | This regression was introduced in | 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 | (Join points). | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13413> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler

1 0

Removing core-spec.pdf from repository?
by Ben Gamari 14 Mar '17

14 Mar '17

Hello everyone, Currently there is a typeset copy of the Core specification in the GHC repository. This means any time someone changes the specification the repository grows by around 300kB. While this isn't the end of the world, it's generally considered bad form to put generated files under version control. Of course, the tools required to typeset the specification (ott and LaTeX) are non-trivial to install, so there is considerable convenience that comes from having a typeset version readily available. I suggest that we remove the PDF from the repository but instead I can start including it in my nightly documentation builds. Any objections? Cheers, - Ben

8 8

RE: Removing core-spec.pdf from repository?
by David Feuer 13 Mar '17

13 Mar '17

Kill it! That's terrible practice indeed. Speaking of generated files, it's time to check if our Unicode tables are up to date. David FeuerWell-Typed, LLP -------- Original message --------From: Ben Gamari <ben(a)well-typed.com> Date: 3/13/17 6:57 PM (GMT-05:00) To: GHC developers <ghc-devs(a)haskell.org> Subject: Removing core-spec.pdf from repository? Hello everyone, Currently there is a typeset copy of the Core specification in the GHC repository. This means any time someone changes the specification the repository grows by around 300kB. While this isn't the end of the world, it's generally considered bad form to put generated files under version control. Of course, the tools required to typeset the specification (ott and LaTeX) are non-trivial to install, so there is considerable convenience that comes from having a typeset version readily available. I suggest that we remove the PDF from the repository but instead I can start including it in my nightly documentation builds. Any objections? Cheers, - Ben

1 0

Trac password change interface restored
by Ben Gamari 13 Mar '17

13 Mar '17

Hello everyone, For the last few weeks Trac's password change functionality has been disabled due to passwords being leaked through the ghc-tickets mailing list. I have updated the Trac configuration to fix this leakage and reenabled this interface. Moreover, we shouldn't see any further email address verifications messages on ghc-tickets. Thanks to everyone for their patience while this was handled. Cheers, - Ben

1 0