September 2017 - ghc-devs

GHC's module hierarchy
by Simon Peyton Jones 02 Oct '19

02 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

Bringing back #ghc IRC logging
by Niklas Hambüchen 25 Oct '17

25 Oct '17

Hi, as you may have noticed, #ghc IRC logging has been broken for months (though the channel topic still says "Logs: http://ircbrowse.net/ghc"). Logs being unavailable is bad because many problems and topics that were googleable before are no longer googleable. We have discussed in the last 2 days on #ghc whether we should just join #ghc with a 0-effort-on-our-side public logging service like botbot.me. This one in particular doesn't have the best UI but I found it to be very googleable, and many open-source projects use it successfully. Is anybody opposed to this? Niklas

4 5

Invariants about UnivCo?
by Nicolas Frisby 11 Oct '17

11 Oct '17

[I summarize with some direct questions at the bottom of this email.] I spent time last night trying to eliminate -dcore-lint errors from my record and variant library using the coxswain row types plugin. I made some progress, but I'm currently stuck, as discussed on this github Issue. https://github.com/nfrisby/coxswain/issues/3#issuecomment-330577609 Here's the relevant bit: The latest unresolved -dcore-lint error is an out-of-scope cobox co var. I'm certainly not creating it *directly* (there are no U(plugin:coxswain,... in the Core Lint warning), but I have to wonder if my somewhat loose use of UnivCo is violating some assumptions somewhere that's causing GHC to drop the co var binding or overlook this occurrence of it on a renaming/subst pass. I checked UnivCo for source comments looking for anything it should *not* be used for, but I didn't find an obvious explanation along those lines. I haven't yet been able to effectively distill the test case. I'm doing this all at -O0. With `-ddump-tc-trace`, I can see the offending cobox (cobox_a67M) is present in an "implication evbinds" listing after a "solveImplication end }" delimiter, but that's the last obvious binding of it. [G] cobox_a67J = CO Sym cobox_a654, [G] cobox_a67M = cobox_a67J `cast` U(plugin:coxswain,...) cobox_a654 is introduced by a GADT pattern match. I'm also not seeing obvious occurrences of cobox_a67M, but I think the reason is that I'm seeing several (Sym cobox) with no uniques printed (even with `-dppr-debug`). Those are probably the cobox in question, but I can't confirm. Questions: 1) Is there a robust way to ensure that covar's uniques are always printed? (Is the pprIface reuse with a free cobox part of the issue here?) 2) Is my plugin asking for this kind of trouble by using UnivCo to cast coboxes? 3) If I spent the effort to create non-UnivCo coercions where possible, would that likely help? This is currently an "eventually" task, but I haven't seen an urgency for it yet. I could bump its priority if it might help. E.G. I'm using UnivCo to cast entire givens when all I'm doing is reducing a type family application somewhere "deep" within the given's predtype. I could, with considerable effort, instead wrap a single, localized UnivCo within a bunch of non-UnivCo "lifting" coercion constructors. Would that likely help? 3) Is there a usual suspect for this kind of situation where a cobox binding is seemingly dropped (by the typechecker) even though there's an occurrence of it? Thank you for your time. -Nick

3 10

In C--: should CmmCall and CmmProc agree on their live registers?
by Moritz Angermann 06 Oct '17

06 Oct '17

Hi, apologies for writing so many emails recently. This is a minor spinoff from the "The Curious Case of T6084" email. While digging into it, I keep asking myself if CmmProc’s live registers should match those of the CmmCall that is calling it? Is there any invariant we try to enforce or would want to enforce? - Can the CmmProcs live registers be a strict superset of the corresponding CmmCalls? From the source comments in `compiler/cmm/Cmm.hs`: > Registers live on entry. Note that the set of live > registers will be correct in generated C-- code, but > not in hand-written C-- code. However, > splitAtProcPoints calculates correct liveness > information for CmmProcs. I would assume that this is an invalid case? - Can the CmmProcs live registers be a strict subset of the corresponding CmmCalls? This case however seems to be valid case. However, this makes me wonder if we can, and should(?) propagate the live register info from the CmmProc to the CmmCall so that they match up, and the registers are not kept live at the origin of the CmmCall if they aren’t needed? And as such potentially compute anything to put into the registers the CmmCall considers live, but the CmmProc would ignore anyway? Cheers, Moritz

2 3

Determine instance method from class method callsite
by Robin Palotai 06 Oct '17

06 Oct '17

Sorry, I messed up subject and mailing list. Copying to both list now after the mistake (wanted only ghc-devs for specificity). Thanks! 2017-09-19 7:36 GMT+02:00 Robin Palotai <palotai.robin(a)gmail.com>: > Hello GHC devs, > > Before inventing the wheel, want to check if there is a GHC API way to > look up the (fully) resolved instance method from a class method. > > For example, given a code > > data Foo Int deriving Show > > bar = show (Foo 3) > > when inspecting the Typechecked AST for bar's show call, I would like to > get to the Name / Id of 'show' of the 'Show' typeclass. > > I believe I could use splitHsSigmaTy on the HsType of the function call to > get the context, and then evaluate the HsWrapper somehow to find out what > instance dictionary is applied to the class restriction in the context, and > then look up the instance method from the dictionary.. > > Two questions: > > 1) Is there maybe functionality for this? > > 2) If not, is there any guarantee about the constraint order in the > context, at the method call? So I could more easily determine which > constraint's application to look for.. > > Any hints welcome && Thank you! > Robin >

2 5

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

5 15

GHC Threads affinity
by Michael Baikov 03 Oct '17

03 Oct '17

Greetings Currently GHC supports two kinds of threads - pinned to a specific capability (bound threads) and those it can migrate between any capabilities (unbound threads). For purposes of achieving lower latency in Haskell applications it would be nice to have something in between - threads GHC can migrate but within a certain subset of capabilities only. I'm developing a program that contains several kinds of threads - those that do little work and sensitive to latency and those that can spend more CPU time and less latency sensitive. I looked into several cases of increased latency in those sensitive threads (using GHC eventlog) and in all cases sensitive threads were waiting for non-sensitive threads to finish working. I was able to reduce worst case latency by factor of 10 by pinning all the threads in the program to specific capability but manually distributing threads (60+ of them) between capabilities (several different machines with different numbers of cores available) seems very fragile. World stopping GC is still a problem but at least in my case is much less frequently so. It would be nice to be able to allow GHC runtime to migrate a thread between a subset of capabilities using interface similar to this one: -- creates a thread that is allowed to migrate between capabilities according to following rule: ghc is allowed to run this thread on Nth capability if Nth `mod` size_of_word bit in mask is set. forkOn' :: Int -> IO () -> IO ThreadId forkOn' mask act = undefined This should allow to define up to 64 (32) distinct groups and allow user to break down their threads into bigger number of potentially intersecting groups by specifying things like capability 0 does latency sensitive things, caps 1..5 - less sensitive things, caps 6-7 bulk things. Anything obvious I'm missing? Any recommendations to how to implement this?

6 10

Disabling Travis?
by Joachim Breitner 02 Oct '17

02 Oct '17

Hi, I wasn’t looking for a while I notice that the travis CI build of GHC has not been succeeding for two months, partly because build time exceeded the already much extended limits we have, partly because support for booting with 7.10 was dropped, but the .travis file was not used. A CI system that is not normally succeeding is pretty pointless, and will only confuse people who submit pull requests over GitHub who see failures. So if noone complains now I will soon disable building on Travis. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

3 14

RTS changes affect runtime when they shouldn’t
by Joachim Breitner 30 Sep '17

30 Sep '17

Hi, while keeping an eye on the performance numbers, I notice a pattern where basically any change to the rts makes some benchmarks go up or down by a significant percentage. Recent example: https://git.haskell.org/ghc.git/commitdiff/0aba999f60babe6878a1fd2cc8410139… which exposed an additional secure modular power function in integer (and should really not affect any of our test cases) causes these changes: Benchmark name prev change now nofib/time/FS 0.434 - 4.61% 0.414 seco nds nofib/time/VS 0.369 + 15.45% 0.426 seco nds nofib/time/scs 0.411 - 4.62% 0.392 sec onds https://perf.haskell.org/ghc/#revision/0aba999f60babe6878a1fd2cc8410139 358cad16 The new effBench benchmarks (FS, VS) are particularly often affected, but also old friends like scs, lambda, integer… In a case like this I can see that the effect is spurious, but it really limits our ability to properly evaluate changes to the compiler – in some cases it makes us cheer about improvements that are not really there, in other cases it makes us hunt for ghosts. Does anyone have a solid idea what is causing these differences? Are they specific to the builder for perf.haskell.org, or do you observe them as well? And what can we do here? For the measurements in my thesis I switched to measuring instruction counts (using valgrind) instead. These are much more stable, requires only a single NoFibRun, and the machine does not have to be otherwise quiet. Should I start using these on perf.haskell.org? Or would we lose too much by not tracking actual running times any more? Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 13