October 2019 - ghc-devs

[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

validate-x86_64-darwin failing
by Richard Eisenberg 14 Oct '19

14 Oct '19

Hi devs, validate-x86_64-darwin seems to be failing. I've restarted it when I came across the failure, but several small patches last night tripped on this. Richard

4 6

CI fails in git submodule update --init --recursive for 386-linux-deb9
by Roland Senn 13 Oct '19

13 Oct '19

Hi After pushing some commits, while running a CI pipeline, I persistently get the following error for the validate-i386-linux-deb9 step: $ git submodule update --init --recursive fatal: Unable to create '/builds/RolandSenn/ghc/.git/modules/libraries/Cabal/index.lock': File exists. Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue. Unable to checkout '63331c95ed15cc7e3d83850d308dc3a86a8c3c76' in submodule path 'libraries/Cabal' See https://gitlab.haskell.org/RolandSenn/ghc/pipelines/11311 . How can I fix this? I have no access to this 386 linux machine, so I'm unable to delete the file. Roland

1 0

ByteArray# as a foreign import argument?
by Shao, Cheng 11 Oct '19

11 Oct '19

Hello devs, I've been trying to figure out how to pass lifted types as foreign types, then encountered the following code in the `DsCCall` module (https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/deSugar/DsCCall.hs#…) ``` -- Byte-arrays, both mutable and otherwise; hack warning -- We're looking for values of type ByteArray, MutableByteArray -- data ByteArray ix = ByteArray ix ix ByteArray# -- data MutableByteArray s ix = MutableByteArray ix ix (MutableByteArray# s) | is_product_type && data_con_arity == 3 && isJust maybe_arg3_tycon && (arg3_tycon == byteArrayPrimTyCon || arg3_tycon == mutableByteArrayPrimTyCon) = do case_bndr <- newSysLocalDs arg_ty vars@[_l_var, _r_var, arr_cts_var] <- newSysLocalsDs data_con_arg_tys return (Var arr_cts_var, \ body -> Case arg case_bndr (exprType body) [(DataAlt data_con,vars,body)] ) ``` It seems we allow a "ByteArray" type as a foreign import argument, if the third field of the datacon is a ByteArray# or MutableByteArray#. But I can't find such a ByteArray type definition in today's common packages. What's the rationale for this piece of code? Cheers, Cheng

4 8

GHC_STAGE
by Shayne Fletcher 10 Oct '19

10 Oct '19

Hi Ben, I observed warnings of this kind in a couple of places building head yesterday: ``` compiler/utils/FastString.hs:336:5: error: warning: 'GHC_STAGE' is not defined, evaluates to 0 [-Wundef] | 336 | #if GHC_STAGE < 2 | ^ #if GHC_STAGE < 2 ^ ``` ``` compiler/main/DynFlags.hs:323:5: error: warning: 'GHC_STAGE' is not defined, evaluates to 0 [-Wundef] | 323 | #if GHC_STAGE >= 2 | ^ #if GHC_STAGE >= 2 ^ ``` I was using the `hadrian/build.stack.sh` approach. Figured you'd want to know! -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.com/>* -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

2 2

Unsquashed merge requests
by Andreas Klebinger 10 Oct '19

10 Oct '19

Hello devs, I've recently seen a few MR's make it into master with commits which rather obviously were meant to be squashed. Please look out for this when assigning MRs to marge. Cheers Andreas

1 0

T13615 fragile?
by Richard Eisenberg 09 Oct '19

09 Oct '19

Hi devs, https://gitlab.haskell.org/rae/ghc/-/jobs/173504 <https://gitlab.haskell.org/rae/ghc/-/jobs/173504> tells me that T13615 failed -- but only in DEBUG mode. My patch is nowhere near this code. Is this a new fragile test? The number of fragile tests seems to be growing quickly. And once a test is labeled fragile, we're essentially no longer tracking the test, if I understand correctly. So that's a bit unfortunate. Thanks, Richard

3 2

slow load and typecheck
by Sam Halliday 09 Oct '19

09 Oct '19

Hello all, I am writing an interactive tool using the ghc api. It is able to load and typecheck a source file in a user's package. I obtain the flags that cabal uses to compile the user's package via the hie-bios trick, and I `parseDynamicFlagsCmdLine' them inside my tool, then I `setTargets' all the home modules (with targetAllowObjCode=True). I use HscNothing and NoLink because I only want access to the trees, I don't want to produce any output files. For the file that I wish to inspect, I `removeTarget' the module and `addTarget` it again but this time providing the full path to the file and don't allow object code. Then I LoadUpTo and typecheck. For the sake of simplicity, let's assume that the file under inspection only has a module definiton and no imports or top levels. Functionally, my code is working great and I am able to do what I want with the typechecked tree. However, load is very slow (~10 seconds user time) on large projects. Here is a cpu time trace of my program (milliseconds): main 1 parse flags 93 load 20436 typecheck 20437 I can enable a bit more ghc timing info via -Rghc-timings and I see !!! Chasing dependencies: finished in 157.20 milliseconds, allocated 528.112 megabytes This seems fine, anything sub-second is ok. But then I see a bunch of home modules in CodeGen that I was not expecting: !!! CodeGen [My.Module.Dependency]: finished in 3335.62 milliseconds, allocated 270.615 megabytes So it looks like the targetAllowObjCode is being ignored... is there any way to force it? Actually I'd prefer to fail fast than to ever compile or codegen a dependency module. I know that it should be possible to load the module a lot faster because if I make a small change in the file under inspection and ask cabal to recompile the module it is super fast (less than a second). Could somebody who understands how incremental/partial compiles work please help me out? PS: If this textual description is confusing, I could put together a minimal reproduction and example project but it will take me some time to do that. -- Best regards, Sam

4 14