March 2016 - ghc-tickets

[GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions
by GHC 19 Sep '17

19 Sep '17

#9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries (other) | Version: Keywords: integer-gmp | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions. If successful, this would - allow to avoid the custom GMP allocator hack, and thus - avoid issues when linking against other C libraries using GMP, - simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now), - and finally maybe even remove a few more superfluous temporary heap allocations. This rewrite can be done incrementally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9281> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #9157: cmm common block not eliminated
by GHC 19 Sep '17

19 Sep '17

#9157: cmm common block not eliminated ------------------------------------+------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- For the toTuple# function (in the attached file) GHC generates a cmm switch statement, with all the alternatives, unsurprisingly, the same. Yet, cmm common block elimination does not kick in. In this particular example, the whole case statement could be annihilated, because all alternatives lead to the same code. BTW, this is how they match in France. {{{ #!ocaml type alt = A of int | B of int | C of int | D of int let g x = match x with A v | B v | C v | D v -> v }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs
by GHC 18 Sep '17

18 Sep '17

#9775: "Failed to remove" errors during Windows build from hsc2hs -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The Windows build over here spews a bunch of errors during the build like the ones below. All of them seem to be related to hsc2hs. The errors do not the build for some reason, so the problem is not critical, but we should look into what's going on here. Note that the errors are indeterministic and the set of files affected varies between builds. Examples: {{{ ghctrace.2/3.log:Failed to remove file libraries/base/dist- install/build/System/CPUTime_hsc_make.exe; error= DeleteFile "libraries/base/dist-install/build/System/CPUTime_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.2/4.log:Failed to remove file compiler/stage2/build/Fingerprint_hsc_make.exe; error= DeleteFile "compiler/stage2/build/Fingerprint_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/1.log:Failed to remove file libraries/hpc/dist- boot/build/Trace/Hpc/Reflect_hsc_make.exe; error= DeleteFile "libraries/hpc/dist-boot/build/Trace/Hpc/Reflect_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/4.log:Failed to remove file libraries/old-time/dist- install/build/System/Time_hsc_make.exe; error= DeleteFile "libraries/old- time/dist-install/build/System/Time_hsc_make.exe": permission denied (Access is denied.) ghctrace.3/5.log:Failed to remove file libraries/Win32/dist- install/build/Graphics/Win32/GDI/Pen_hsc_make.exe; error= DeleteFile "libraries/Win32/dist-install/build/Graphics/Win32/GDI/Pen_hsc_make.exe": permission denied (Access is denied.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10601: GHC should be distributed with debug symbols
by GHC 16 Sep '17

16 Sep '17

#10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that we have the capability of producing code with DWARF symbols, we should distribute GHC with them, or at least give the option. The DWARF symbols in these case would be both for the C RTS and for the base Haskell libraries shipped with GHC. Building GHC with said symbols amounts to adding {{{ GhcRtsHcOpts += -g GhcLibHcOpts += -g }}} to `mk/build.mk`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11649: LLVM code generator produces mal-formed LLVM blocks
by GHC 15 Sep '17

15 Sep '17

#11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that the recent addition (673efccb3b348e9daf23d9e65460691bbea8586e) of some instances for types in `GHC.Generics` has uncovered a bug in the LLVM code generator (at least on ARM). `libraries/base/GHC/Generics.hs` fails to compile with, {{{ Entry block to function must not have predecessors! label %cjGw /home/ben/ghc/roots/llvm-3.7/bin/opt: libraries/base/GHC/Generics.ll: error: input module is broken! }}} The problematic block in question appears to be, {{{ define internal ghccc void @rhSw_info$def(i32* noalias nocapture %Base_Arg, i32* noalias nocapture %Sp_Arg, i32* noal ias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg) align 4 nounwind prefix <{ i32, i32, i32}><{i32 65541, i32 0, i32 15}> { clpH: br label %clpH } }}} Which arose from this Cmm, {{{ ==================== Post control-flow optimisations ==================== 2016-02-26 10:39:28.656744 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [] { info_tbl: [(clpH, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 0 updfr_space: Nothing } {offset clpH: goto clpH; // CmmBranch } }] }}} Which arose from this input Cmm, {{{ ==================== Cmm produced by new codegen ==================== 2016-02-26 10:39:28.611641 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [R2] { info_tbl: [(clpD, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 4 updfr_space: Just 4 } {offset clpD: _shWa::P32 = R2; // CmmAssign goto clpz; // CmmBranch clpz: if ((old + 0) - <highSp> < SpLim) goto clpE; else goto clpF; // CmmCondBranch clpE: R2 = _shWa::P32; // CmmAssign R1 = lvl_rhSw_closure; // CmmAssign call (stg_gc_fun)(R2, R1) args: 4, res: 0, upd: 4; // CmmCall clpF: goto clpy; // CmmBranch clpy: goto shWb; // CmmBranch shWb: goto clpH; // CmmBranch clpH: goto shWb; // CmmBranch } }] }}} Which arose from this STG, {{{#!hs lvl_rhSw :: forall a_a99i. GHC.Generics.U1 a_a99i -> GHC.Generics.U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <L,U>x, Unf=OtherCon []] = sat-only \r [eta_shWa] let-no-escape { some_v_shWb [Occ=LoopBreaker] :: GHC.Generics.U1 [a12_a99i] [LclId, Str=DmdType b] = NO_CCS[] \u [] some_v_shWb; } in some_v_shWb; }}} Which arose from this Core, {{{#!hs lvl_rhSw :: forall a_a99i. U1 a_a99i -> U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <L,U>x] lvl_rhSw = \ (@ a12_a99i) _ [Occ=Dead] -> letrec { some_v_a99l [Occ=LoopBreaker] :: U1 [a12_a99i] [LclId, Str=DmdType b] some_v_a99l = some_v_a99l; } in some_v_a99l }}} Which is apparently the body of the `some` implementation in the `Alternative` instance for `GHC.Generics.U1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11649> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks
by GHC 14 Sep '17

14 Sep '17

#10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks -------------------------------------+------------------------------------- Reporter: | Owner: TobyGoodwin | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown performance | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: see ticket | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been studying a compiler performance problem in ghc-7.8.4 which is not seen in ghc-7.6.3. Profiling shows the compiler spends 74.3% of its time in `elimCommonBlocks` (in `compiler/cmm/CmmCommonBlockElim.hs`). I came across the problem in real code, and rwbarton on #ghc was able to turn it into a sensible test case, which can be found at http://static.tobold.org/ghc-prof/code/ It's not really a regression, since `elimCommonBlocks` is not enabled by default in 7.6. It can be turned on with `-fnew-codegen`, and that demonstrates a similar slowdown. However 7.8 is worse than 7.6, and 7.10 slightly worse still, for reasons that I haven't explored. Compile times for `RegBig.hs` are: {{{ 7.6.3 -O2 17s 7.6.3 -O2 -fnew-codegen 177s 7.8.4 -O2 230s 7.10.1 -O2 241s }}} The problem obviously stems from the applicative expression with lots of branches `Foo <$> a <*> b <*> c <*> ...` It seems that some level of inlining occurs which means that each extra term in this expression doubles the size of the code. Incidentally, this blowup only occurs when both `RegBig.hs` ''and'' `Form.hs` are compiled with `-O2`. I haven't looked to see why the blowup occurs; although I do see that a similar blowup happens with 7.6. {{{ ... *** Simplifier: Result size of Simplifier iteration=1 = {terms: 16,525, types: 31,503, coercions: 73} Result size of Simplifier iteration=2 = {terms: 29,070, types: 45,079, coercions: 73} Result size of Simplifier iteration=3 = {terms: 50,139, types: 62,057, coercions: 73} Result size of Simplifier iteration=4 = {terms: 84,172, types: 83,805, coercions: 73} Result size of Simplifier = {terms: 84,172, types: 83,805, coercions: 73} ... }}} I've looked in some detail at what happens next, tinkering with `elimCommonBlocks` to try to understand why it runs so slowly in this case. There are two major problems. First, `elimCommonBlocks` is worse than O(n^2^), and the inlining blowup mentioned above results in a very large input: 51695 blocks in this example. (Across the project of 50 files or so where this problem originated, I see the input to `elimCommonBlocks` is normally a few hundred blocks at most.) Secondly, there is an effort made in `elimCommonBlocks` to avoid comparing whole blocks all the time, by computing a hash value of some of the block. This fails to produce sufficient unique hash values for this case. The hash must obviously omit the unique block label, and in practice all labels, and various other things, are omitted. In this case, presumably because the code is blown up from the tiny input, many many blocks are similar, and the differences are elided by the hash function. For example, 8177 blocks share the hash value 1094. These 8177 similar blocks all end up in a normal list, which is searched with Data.List.find and the full-block comparison function! Eventually this process concludes that the vast majority are in fact different: for all its hard work, `elimCommonBlocks` only finds about a dozen common blocks in total. Two blocks which both hash to 1094 are these: {{{ cCHc: _se0q::P64 = R1; _c1grM::P64 = _se0q::P64 & 7; if (_c1grM::P64 >= 2) goto c1grR; else goto c1grS; cWK7: _sig3::P64 = R1; _c1iXk::P64 = _sig3::P64 & 7; if (_c1iXk::P64 >= 2) goto c1iXp; else goto c1iXq; }}} I suggest the following steps need to be taken. == 1. Mitigation == Since this is a real problem in the 7.8 and 7.10 series, it needs a simple but effective mitigation. I suggest a test that the input to `elimCommonBlocks` is not "too big", where 1000 seems a reasonable cutoff. Another simple mitigation would be to disable common block elimination altogether (after all, `-O2` is usually understood to mean "make my code go faster even if it gets bigger"). I've tried both these possibilities with 7.8.4. The trivial patches are http://static.tobold.org/ghc-prof/0001-cbe-cutoff.patch and http://static.tobold.org/ghc-prof/0001-no-cbe.patch Compilation times for the test case `RegBig.hs` are as follows, and there is no difference in size in the `.o` file. {{{ 7.8.4 -O2 230s cbe only if input < 1000 blocks 88s no common block elimination 86s }}} == 2. Investigation == I focused on `elimCommonBlocks` thinking that the inline blowup seen earlier in the compilation is reasonable. On reflection, this is probably not so, and I think someone better acquainted with ghc internals should investigate this. == 3. Optimization == `-- TODO: Use optimization fuel` it says in `CmmCommonBlockElim.hs` Since `elimCommonBlocks` is essentially doing a `nub`, it will never perform better than O(n^2^). In fact, it's currently much worse than that as the comparison function changes as duplicate blocks are found, which in turn may create new duplicates, so we have to iterate the nub function till no more dups are found. I did experiment with improving the hash function. It's possible to include target labels, at the expense of needing to recompute block hash values on each iteration. (And currently some ''highly'' ugly code to convert labels to integers.) This considerably reduces the length of some of the hash bucket lists, and so offers a significant speedup: {{{ ghc-7.8.4 -O2 230s "hack" 170s }}} Patch for this is http://static.tobold.org/ghc-prof/0001-cbe-hacks.patch This looks like a promising approach. Including target labels doesn't eliminate all the large hash buckets, so there is scope for further improvements along these lines. I don't see any reason why the hash function should not be as discerning as the equality function, with just occasional accidental clashes. I've also pondered whether more radical rewriting of `elimCommonBlocks` might pay dividends. It's a commonplace that, if you don't need to preserve order, `map head . group . sort` is a faster `nub`. Is the order of blocks significant? I'm not sure - they all seem to end with either `goto` or `call`. I'd ''assume'' that `call` then falls through to the next block but I'm not sure. Anyway, presumably we could `zip [0..]` first, and sort again afterwards, and that should still be asymptotically faster than `nub`. Of course, this presupposes that blocks could be (sensibly? efficiently?) made an instance of `Ord`. (If they were, hash buckets could be stored in an O(1) data structure and binary search employed.) I may be able to find time to pursue some of these avenues, but as a very novice ghc hacker, I'd need some strategic direction here. Any thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10397> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 42

[GHC] #8091: retry# lacks strictness information
by GHC 13 Sep '17

13 Sep '17

#8091: retry# lacks strictness information ------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The `retry#` primop should be marked as returning bottom since it never actually returns anything as far as the simplifier is concerned. This change would help the simplifier eliminate unreachable code inside STM transactions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8532: Hyperbolic arc cosine fails on (-1) :: Complex r.
by GHC 13 Sep '17

13 Sep '17

#8532: Hyperbolic arc cosine fails on (-1) :: Complex r. -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Incorrect result Difficulty: Easy (less than 1 | at runtime hour) | Test Case: acosh(-1) :: Blocked By: | Complex Double Related Tickets: | Blocking: -------------------------------------+------------------------------------- When allowing for complex results, the hyperbolic arc cosine is continuously defined on all ℝ. In the {{{(x < (-1))}}} real ray of the complex plane, {{{acosh}}} equals {{{\z -> i * pi + acosh(abs z)}}}, which works fine for almost all arguments. Thus, {{{acosh (-1)}}} should equal {{{i * pi}}}; however due to the implementation as {{{ acosh z = log (z + (z+1) * sqrt ((z-1)/(z+1))) }}} where the denominator in the root becomes zero at {{{z = -1}}}, this comes out as {{{NaN :+ NaN}}}. Could be fixed trivially by adding a special case {{{ acosh ((-1):+0) = 0:+pi }}} to the {{{instance (RealFloat a) => Floating (Complex a)}}} in {{{Data.Complex}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8532> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #8583: Associated pattern synonyms
by GHC 11 Sep '17

11 Sep '17

#8583: Associated pattern synonyms ------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: 5144 | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The PatternSynonyms wiki page has a section on (typeclass-)associated pattern synonyms: {{{ class ListLike l where pattern Nil :: l a pattern Cons :: a -> l a -> a isNil :: l a -> Bool isNil Nil = True isNil (Cons _ _) = False append :: l a -> l a -> l a instance ListLike [] where pattern Nil = [] pattern Cons x xs = x:xs append = (++) headOf :: (ListLike l) => l a -> Maybe a headOf Nil = Nothing headOf (Cons x _) = Just x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8583> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10818: GHC 7.10.2 takes much longer to compile some packages
by GHC 11 Sep '17

11 Sep '17

#10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu- | Owner: yamamoto | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- If we compile the iproute package by GHC, GHC 7.10.2 take much longer than GHC 7.8.4. See the report from Travis CI: https://travis-ci.org/kazu-yamamoto/iproute/builds/77427248 I can reproduce this on my local MacBookAir: - GHC 7.8.4: cabal build 8.81s user 0.94s system 103% cpu 9.430 total - GHC 7.10.2: cabal build 37.86s user 3.49s system 98% cpu 42.066 total -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25