March 2014 - ghc-tickets

[GHC] #8685: -split-objs doesn't work for executables
by GHC 08 Mar '19

08 Mar '19

#8685: -split-objs doesn't work for executables ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | 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: | ------------------------------------+------------------------------------- While investigating [this bug report](https://github.com/haskell/cabal/issues/1611), I've noticed that the `-split-objs` option only works for libraries, but not for executables. That is, unlike in the case of libraries, the driver feeds only `A.o B.o ...` files to the linker instead of `A_split_0.o A_split_1.o ... B_split_0.o B_split_1.o ...`. It'd be nice if `-split-objs` could be changed to also work on executables. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation
by GHC 08 Mar '19

08 Mar '19

#8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ------------------------------------+--------------------------------- Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: ios | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- I have been trying to statically link Pandoc packages to iOS application following the guide in https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS and it's great so far! I have finally successfully use Pandoc library in iOS app, but the binary size is very big! 1. More than 50MB when using Pandoc library. 2. Around 5MB for simple haskell code. I try to add “split-objs: True” in .cabal/config file, but when running cabal I got this message: {{{ Preprocessing library pandoc-1.12.2.1... unused terminals: 1 on the commandline: Warning: ignoring -fsplit-objs }}} And if I ignore that, at the end of build, I get another error message that stop the build. {{{ cabal: dist-i386/build/Text/Pandoc_o_split: does not exist }}} I try with another package and got similar error message. It seems that split-objs not only being ignored by cross-compilation ghc, but will also fail the build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8095: TypeFamilies painfully slow
by GHC 08 Mar '19

08 Mar '19

#8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | -------------------------------------+------------------------------------- I'm using the TypeFamilies extension to generate types that are quite large. GHC can handle these large types fine when they are created manually, but when type families get involved, GHC's performance dies. Unlike in ticket #5321, using tail recursion does not eliminate the problem, and the order of arguments greatly affects compile time. I've attached a file Types.hs that demonstrates the problems. This file generates another Haskell file which has the problems. It takes 3 flags. The first is the size of the type to generate, the second is which type family function to use, and the third is whether to call the type family or just use a manually generated type. Here are my performance results: Using non-tail recursion, I get these results. I have to increase the stack size based on the size of the type I want to generate. {{{ $ ./Types 200 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m2.973s $ ./Types 300 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=350 real 0m6.018s $ ./Types 400 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=450 real 0m9.995s $ ./Types 500 a a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=550 real 0m15.645s }}} Tail recursion generates much slower compile times for some reason, and I still need to adjust the stack size: {{{ $ ./Types 200 b a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m16.120s }}} Changing the order of arguments to the recursive type family greatly changes the run times: {{{ $ ./Types 200 c a > test.hs && time ghc test.hs > /dev/null -fcontext- stack=250 real 0m6.095s }}} Without the type family, I get MUCH better performance: {{{ $ ./Types 10000 a d > test.hs && time ghc test.hs > /dev/null real 0m2.271s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #8657: -fregs-graph still has a limit on spill slots
by GHC 04 Mar '19

04 Mar '19

#8657: -fregs-graph still has a limit on spill slots -----------------------------------+--------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- The limit on spill slots was removed for the linear register allocator in 7.8, but not for `-fregs-graph`. SHA-1 fails to compile with `-fregs-graph` in 7.8. Related: #7679 (`-fregs-graph` generates poor code with the new codegen). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8657> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes
by GHC 08 Feb '19

08 Feb '19

#8635: GHC optimisation flag ignored when importing a local module with derived type classes ------------------------------------+------------------------------------- Reporter: NeilMitchell | 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: | ------------------------------------+------------------------------------- Given Foo.hs and Bar.hs: {{{ module Foo where data Food = Food -- deriving Eq {-# OPTIONS_GHC -O2 -ddump-simpl #-} module Bar where import Foo bar :: Int -> Bool bar x = x == 72 }}} If I run: {{{ ghc --make Bar -fforce-recomp }}} I get (snipped): {{{ Bar.bar = \ (x_afk :: GHC.Types.Int) -> case x_afk of _ { GHC.Types.I# x1_alo -> case x1_alo of _ { __DEFAULT -> GHC.Types.False; 72 -> GHC.Types.True } } }}} `bar` now looks pretty well optimised. However, if I uncomment the `deriving Eq` I get: {{{ Bar.bar1 = GHC.Types.I# 72 Bar.bar2 = GHC.Classes.== @ GHC.Types.Int GHC.Classes.$fEqInt Bar.bar = \ (x_amD :: GHC.Types.Int) -> Bar.bar2 x_amD Bar.bar1 }}} Now `bar` looks like terrible code, using dictionaries, boxing etc. It seems adding `deriving` in the imported and unused module makes it ignore the optimisation level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8326: Place heap checks common in case alternatives before the case
by GHC 07 Jan '19

07 Jan '19

#8326: Place heap checks common in case alternatives before the case ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | ------------------------------------+------------------------------------- We would like to have functions that check whether an `Int#` is a valid tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim): {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False isFalse# :: Int# -> Bool isFalse# 0# = True isFalse# _ = False }}} We could use them with comparison primops like this: {{{ f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} `isTrue#` is optimized away at the Core level: {{{ A.f = \ (x_aqM :: GHC.Prim.Int#) -> case GHC.Prim.># x_aqM 0 of _ { __DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM); 1 -> GHC.Types.I# x_aqM } }}} but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives: {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} This results in average 2.5% increase in binary size. By contrast, if we use `tagToEnum#` instead of `isTrue#` heap check will be placed before `case` expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see #8317). What we would like to do here is: 1. compile case alternatives without placing heap checks inside them 2. each compiled alternative should return amount of heap it needs to allocate 3. code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression. Getting this right might be a bit tricky. 1. if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly. 2. if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve #1498. 3. it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the `case` expression we lose optimization of recursive functions and face the problem described in #1498. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic
by GHC 01 Jan '19

01 Jan '19

#8611: nofib’s cacheprof’s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <<ghc: 127588752 bytes, 243 GCs, 2261288/6551032 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.12 elapsed), 0.05 GC (0.05 elapsed) :ghc>> ./cacheprof +RTS -t <<ghc: 127392144 bytes, 242 GCs, 2261304/6551576 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (0.11 elapsed), 0.04 GC (0.05 elapsed) :ghc>> }}} The allocations numbers change, when they shoudn’t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8316: GHCi debugger segfaults when trying force a certain variable
by GHC 28 Dec '18

28 Dec '18

#8316: GHCi debugger segfaults when trying force a certain variable ------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The file Test.hs has following definitions: {{{ whnf :: a -> IO () whnf a = a `seq` (return ()) foo :: [Int] foo = [1..] }}} Calling ghci as: {{{ ghci Test.hs -ignore-dot-ghci }}} and bebugging foo like this: {{{ *Main> :b foo Breakpoint 0 activated at Test.hs:5:7-11 *Main> foo Stopped at Test.hs:5:7-11 _result :: [Int] = _ [Test.hs:5:7-11] *Main> :p foo foo = (_t1::[Int]) [Test.hs:5:7-11] *Main> whnf _t1 }}} results in this segault: {{{ <interactive>: internal error: TSO object entered! (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 5445 abort (core dumped) ghci Test.hs -ignore-dot-ghci }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #8655: Evaluate know-to-terminate-soon thunks
by GHC 19 Dec '18

19 Dec '18

#8655: Evaluate know-to-terminate-soon thunks ------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | 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: | ------------------------------------+------------------------------------- I guess I’ll better put my interior monologue in a ticket than on ghc- dev... In order to implement nested CPR (#1600), I had to enrich the CPR type to keep track of whether something, when entered, will converge for sure. My code does not solve the halting problem, but does only simple stuff, so if something is known to converge, is is very likely to be cheap. Simon suggested to measure the effect of evaluating a let-bound thunk with the known-to-terminate property, as if the body was using it strictly. This tickets tracks this suggestion, and reports progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8655> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8598: IO hack in demand analyzer gets in the way of CPR
by GHC 19 Dec '18

19 Dec '18

#8598: IO hack in demand analyzer gets in the way of CPR ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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: | ------------------------------------+------------------------------------- After a lot of staring at code and comparing unexpected nofib results I found the following: The IO hack in the demand analyzer (see `dmdAnalAlt` in `StrAnal.lhs` and #1592 for a good discussion) prevents CPR in any function that uses a C call. This is a small example, reduced from the `scaleFloat` method for doubles: {{{ module Float(fun) where import GHC.Float (Double(..)) import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) fun :: Double -> Double fun x | isFix = x | otherwise = case x of (D# x#) -> case decodeDoubleInteger x# of (# i, j #) -> D# (encodeDoubleInteger i j) where isFix = isDoubleFinite x == 0 foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} Here, `fun` does current not get the CPR property, and the work gets type `GHC.Prim.Double# -> GHC.Types.Double`. Why? Because in core, there will be a {{{ case {__pkg_ccall main isDoubleFinite GHC.Prim.Double# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Int# #)}_dQD ds_dQA GHC.Prim.realWorld# of _ [Occ=Dead, Dmd=<L,A>] { (# ds_dQC [Dmd=<L,A>, OS=OneShot], ds_dQB [Dmd=<S,1*U>] #) -> ... }}} where the case body has `DmdType m {dQz-><L,1*U(U)> dQA-><L,U>}`, but `dmdAnalAlt` detects that this is evaluating a possibly exiting function and throws aways the information using `alt_ty `lubDmdType` topDmdType`. Would it be ok to `lub` only the demand on the free variables, but keep the CPR information? In nofib (if I managed to compare the right results) this does nothing for almost all benchmarks, `-9.2%` of allocations for `mandel` and `+4.9%` for reverse-complement (but these numbers are not obtained very cleanly, and all is happening on top of the better-ho-cardinality branch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8598> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15