- ghc-devs - Haskell.org

A possible bug in ghc documentation
by yi lu 20 Mar '17

20 Mar '17

Hi all, Sorry to bother. I'm not sure if this is the right place to post this, but I find a possible bug in ghc documentation. http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/flags.html#la… ^In 7.6.12, -XDeriveGeneric <http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.…> appears twice. If it is a bug, please fix. Thanks. Yi

2 1

PSA: perf.haskell.org/ghc temporarily out of order
by Joachim Breitner 20 Mar '17

20 Mar '17

Hi, a recent change to nofib (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3…) broke the perf.haskell.org builder, so we won’t be getting perf warnings until that is fixed. I hope that once its up we will not be faced with a large number of performance changes that we will have to track down. 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

3 7

Stat too good
by Simon Peyton Jones 19 Mar '17

19 Mar '17

Ben, I still get these four stat-too-good "failures" on 64-bit Linux. Unexpected stat failures: /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T13035.run T13035 [stat too good] (normal) /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T12425.run T12425 [stat too good] (optasm) /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T1969.run T1969 [stat too good] (normal) /tmp/ghctest-ca0gfq/test spaces/./perf/compiler/T9233.run T9233 [stat too good] (normal) Don't you? Simon

3 2

Compiling CMM tests with LLVM
by Erik de Castro Lopo 18 Mar '17

18 Mar '17

Hi all, I'm working on a minor change to CMM (#13442) and while writing the tests realized that the CMM tests were only run with `-fasm` and not with `-fllvm`. Furthermore other than running the test manually myself, I could not figure out how to make it compile with LLVM. My test (in my WIP local branch) is: testsuite/tests/codeGen/should_compile/T13442.cmm and I updated the `all.T` in that same directory with the line: test('T13442', [cmm_src], compile, ['-dcmm-lint']) Anyone have any clues as to how to make this compile with LLVM if LLVM is available? I suspect it should probably be turned on for the vast majority of the CMM tests. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 1

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