- ghc-devs - Haskell.org

Debugging specialization
by Alexis King 28 Oct '19

28 Oct '19

Hi all, I am trying to understand why GHC is not specializing an imported INLINABLE instance method, and the information provided by -ddump-spec -Wall-missed-specialisations has not been enough to help me figure it out. Is there some easy/well-trodden way that I could build GHC with some additional instrumentation in place to help me better understand the decisions being made by the specializer, or is -ddump-spec the most granularity available? I’ve noticed that Specialise.hs has handful of pprTrace calls sprinkled about, but they are all commented out. Is the recommended method to just uncomment these calls and rebuild GHC? Thanks, Alexis

3 3

ghc, rts/Linker.c, OpenBSD and WXNEEDED and NOPIE
by Matthias Kilian 28 Oct '19

28 Oct '19

Hi, tl;dr: with shared / dynamic libs, is anything from rts/Linker.c still in use? If so, where and why? I hope this hasn't already been discussed in the past, and I apolotzie if all this is no longer relevant for ghc-8.8 or newer (I'm still at 8.6)... On OpenBSD, I had to explicitely mark ghc as WXNEEDED (i.e. allow it to map pages both as writable and executable), which I would like to get rid of. Likewise, I had to do some dances to explicitely disable PIE. If my memory doesn't fail completely, most (if not all) oft his was because of rts/Linker.c mmapping objects to be loaded at runtime and kind of simulating what dlopen() does for shared objects. Recently, thanks to Greg Steuck (who helped me a lot with this), we updated our ghc port to ghc-8.6 and also enabled shared (or dynamic, if you prefer this term) libraries. So my hope was that the code in rts/Linker.c were no longer used (because dynamic loading as done by ghci or template Haskell) could be done with dlopen(). However, after building ghc-8.6 with all the WXNNEDED stuff removed, and running ghci from this build, I still get an abort because pages are mapped both writable and executable (I've configured my system to abort processes when a W^X violation happens). Here's a backtrace in case it's helpfull at all: #0 _thread_sys___syscall () at -:3 #1 0x00000002010bb179 in _libc_mmap (addr=Variable "addr" is not available.) at /usr/src/lib/libc/sys/mmap.c:47 #2 0x000000021be22374 in mmapForLinker (bytes=Variable "bytes" is not available.) at rts/Linker.c:1029 #3 0x000000021be3e99b in m32_allocator_init () at rts/linker/M32Alloc.c:160 #4 0x00000002fd518be1 in cimc_info () from /usr/local/lib/ghc/bin/../ghci-8.6.4/libHSghci-8.6.4-ghc8.6.4.so #5 0x0000000000000000 in ?? () Any thougts about this? And, since W|X (and nopie) isn't good on any system: is anyone working on getting rid of this for other unixes? Thanks in advance for any help. Ciao, Kili

2 1

How to navigate around the source tree?
by Matthew Pickering 25 Oct '19

25 Oct '19

Hi, The module rework has broken my workflow. Now my tags file is useless for jumping for modules as there are multiple "Utils" and "Types" modules. Invariable I am jumping to the wrong one. What do other people do to avoid this? Can we either revert these changes or give these modules unique names to facilitate that only reliable way of navigating the code base. Perhaps `HsUtils` and `StgUtils` would be appropriate to disambiguate `Hs/Utils` and `StgToCmm/Utils`. Cheers, Matt

8 12

Urgent: git problem
by Simon Peyton Jones 23 Oct '19

23 Oct '19

Aieee! All my GHC repos are failing with this. As a result I can't pull. What should I do? Thanks! Simon git pull error: cannot lock ref 'refs/remotes/origin/wip/rae/remove-tc-dep': 'refs/remotes/origin/wip/rae' exists; cannot create 'refs/remotes/origin/wip/rae/remove-tc-dep' >From gitlab.haskell.org:ghc/ghc ! [new branch] wip/rae/remove-tc-dep -> origin/wip/rae/remove-tc-dep (unable to update local ref) error: cannot lock ref 'refs/remotes/origin/wip/rae/split-up-modules': 'refs/remotes/origin/wip/rae' exists; cannot create 'refs/remotes/origin/wip/rae/split-up-modules' ! [new branch] wip/rae/split-up-modules -> origin/wip/rae/split-up-modules (unable to update local ref) simonpj@MSRC-3645512:~/code/HEAD-2$

6 9

Why is libraries/ghci built with stage 0 compiler instead of stage 1?
by Ömer Sinan Ağacan 18 Oct '19

18 Oct '19

Stage 1 compiler doesn't have interpreter, and doesn't run plugins or TH, so I think GHCi stuff should not be used by stage 1 compiler, but for some reason the "ghci" library (libraries/ghci) is built with stage 0 compiler instead of stage 1. Anyone know what this is? Thanks, Ömer

2 1

atomicModifyMutVar2
by Simon Peyton Jones 17 Oct '19

17 Oct '19

David I'm deeply puzzled atomicModifyMutVar2#. I have read the proposal<https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0149-a…>, and the comments in primops.txt.pp (reproduced below). Question 1 I think the "real" type of atomicModifyMutVar2 is atomicModifyMutVar2# :: MutVar# s a -> (a -> (a,b)) -> State# s -> (# State# s, a, (a, b) #) Nowhere is this explicitly stated, but I believe that the intended semantics of a call case (atomicModifyMutVar2# mv f s) of (# s', x, r #) -> blah Then, suppose the old value of the MutVar was 'old' * The primop builds a thunk t = f old * The new value of the mutable variable is (fst t) * The result r is t * The result x is old Question: is that correct? We should state it explicitly. Question 2 Next question: Why does f have to return a pair? So far as I can tell, it's only so that a client can force it. The 'b' part never seems to play a useful role. So we could equally well have had atomicModifyMutVar2# :: MutVar# s a -> (a -> Box a) -> State# s -> (# State# s, a, Unit a #) where Unit is defined in Data.Tuple data Unit a = Unit a Now you can force the result of (f old), just as with a pair. But the 'b' would no longer complicate matters. Question: is the 'b' in the pair significant? Or could we use Unit? Question 3 In the comments below you say "but we don't know about pairs here". Are you sure? What stops you importing Data.Tuple into GHC.Prim? This fancy footwork is one more complication, if it could be avoided. Thanks Simon primop AtomicModifyMutVar2Op "atomicModifyMutVar2#" GenPrimOp MutVar# s a -> (a -> c) -> State# s -> (# State# s, a, c #) { Modify the contents of a {\tt MutVar\#}, returning the previous contents and the result of applying the given function to the previous contents. Note that this isn't strictly speaking the correct type for this function; it should really be {\tt MutVar\# s a -> (a -> (a,b)) -> State\# s -> (\# State\# s, a, (a, b) \#)}, but we don't know about pairs here. } with out_of_line = True has_side_effects = True can_fail = True

3 12

Re: [Reminder] Merge window for 8.10 closing
by Ryan Scott 16 Oct '19

16 Oct '19

I've been working on a fix for #13154 [1] that I'd like to get into GHC 8.10. My patch [2] is mostly done; I just need to find the time to add comments and perform some slight code cleanup. (Hopefully this week!) Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/issues/13154 [2] https://gitlab.haskell.org/RyanGlScott/ghc/tree/wip/T13154-take-two

1 0

[Reminder] Merge window for 8.10 closing
by Ben Gamari 16 Oct '19

16 Oct '19

Hello everyone, As described on the GHC status page [1] the freeze for GHC 8.10 is coming up shortly. If you have work that you would like to get into 8.10 and haven't yet opened an MR you should either do so today or be in touch with me. After this freeze begins there will be approximately a week of reduced merge rate to let the master branch settle before the branch, which could happen as early as early next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/54?title=8.10.1

2 1

Help with debugging a batch mode (or type checker) bug
by Ömer Sinan Ağacan 15 Oct '19

15 Oct '19

Hi, In !1304 I'm currently having a bug where I get correct IdInfos for imported Ids in one-shot mode (-c), but not when I use batch mode (--make). If I add a few prints I can see that in hscIncrementalCompile right before hscIncrementalFrontend the hsc_HPT has the correct IdInfos for the imported Ids, but somehow in the desugarer output the IdInfo is lost. Can anyone point me to the right places in the typechecker or the desugarer for me to look at? Thanks, Ömer

2 4

Switch/Case optimisations
by chessai . 14 Oct '19

14 Oct '19

I thought Andreas Klebinger in particular might find this interesting. The talk is here: https://youtu.be/IAdLwUXRUvg?t=1867 (timestamp is 31:07) basically, if you have an interpreter consisting of a switch statement inside an infinite loop, there's a mechanical transformation using GOTOs that causes a 15% speedup in the switch statement blob, there's n + 1 basic blocks, each of which has a jmp back to the first basic block with probability 1, and the first basic block has a jmp that will go to one of the other n basic blocks with probability 1 / n whereas in the goto statement setup, there's n basic blocks, each of which has a jmp that will go to one of the other n - 1 basic blocks with probability 1 / (n - 1) so if your sequence of instructions is produced by a markov decision process, then the branch predictor will efficiently predict in the latter situation but not necessarily the former in the goto setup the callgraph looks like a complete graph on n vertices whereas in the switch setup it looks like a bipartite graph on (1, n) vertices (where the edges represent both "is called by" and "calls") and because of all those extra edges (n^2 rather than 2n) there's more spots for the branch predictor to build up data At 39:13 he explains that you get per-address jmp predictions. If you only share a single relative jmp, the cpu only knows how common every opcode is. But, if you have a jmp from each opcode, to the next, the cpu can determine how common an opcode A is followed an opcode B. He references godbolt (https://godbolt.org/) which seems like a useful tool. and mentions that ruby, jvm (on android only?), and some arm compilers implement this. There are some tradeoffs - code size does increase. According to a GCC developer in the audience, GCC is not currently able to do this. I have no idea about Clang. Thanks

1 0