June 2014 - ghc-tickets

[GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm
by GHC 08 Mar '19

08 Mar '19

#8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile-time Difficulty: Easy (less than 1 | crash hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- ...since the pretty-printer attempts to force the blocks list of the split_marker_entry proc. I'm not really sure what the right way to fix this is: just provide an empty block list, or hack the pretty-printer to treat split markers specially. But should be easy to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8964> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #9121: Presence of dyn_o files not checked? upon recompilation
by GHC 28 Feb '19

28 Feb '19

#9121: Presence of dyn_o files not checked? upon recompilation ------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When I interrupt a compilation (initiated with cabal), and then recompile (with cabal), it can happen that gcc fails with missing .dyn_o file. I have "shared:True" in my .cabal/config file. [I can of course do cabal clean to work around, but since a full recompilation is about 10 min, I try to avoid this.] time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [239 of 273] Compiling Agda.TypeChecking.Conversion ( src/full/Agda/TypeChecking/Conversion.hs, dist/build/Agda/TypeChecking/Conversion.o ) [Agda.Syntax.Translation.InternalToAbstract changed] ^Cmake: *** [install-bin] Interrupt time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file or directory Failed to install Agda-2.3.3 cabal: Error: some packages failed to install: Agda-2.3.3 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #9173: Better type error messages
by GHC 27 Jan '19

27 Jan '19

#9173: Better type error messages ------------------------------------+------------------------------------- Reporter: simonpj | 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: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Generating better type-error messages is a hoary chestnut, but Herbert brought my attention to [https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_begi… this thread on reddit], which has the following idea. At the moment, from {{{ module Foo where addThree = \x -> x + 3 :: Int y = addThree $ Just 5 }}} we get this error: {{{ Foo.hs:2:20 Couldn't match expected type `Int' with actual type `Maybe a0' In the return type of a call of `Just' In the second argument of `($)', namely `Just 5' In the expression: addThree $ Just 5 }}} Maybe we could generate this instead {{{ Foo.hs:2:20 inferred: "Just 5" has type "Maybe a0" expected: second argument of "($)" must have type "Int" in the expression: addThree $ Just 5 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 37

[GHC] #9251: ghc does not expose brancheless max/min operations as primops
by GHC 22 Jan '19

22 Jan '19

#9251: ghc does not expose brancheless max/min operations as primops ------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | ------------------------------------+------------------------------------- It was pointed out in #9246 that GHC currently does not expose primops for Max and Min on various unlifted types such as Float# and Double# and Int# and Word#, but that on most modern CPU architectures there is instruction level support for these operations. (Eg, Float# and #Double min and max can be provided on any 64bit x86 system pretty easily ) This ticket is to track doing that task. I'll probably do it one of the next two weekends to get back in the GHC hacking groove, or maybe this should be used as a "getting started" ticket for a new contributor? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[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