- ghc-tickets - Haskell.org

[GHC] #16040: Unboxing-Related Performance Issue with Polymorphic Functions
by GHC 23 Dec '18

23 Dec '18

#16040: Unboxing-Related Performance Issue with Polymorphic Functions -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My team has observed a 2x performance degradation in code that makes use of `StateT` that appears to be related to strictness and unboxing, even when built with `-O2`. Our code makes heavy use of the state monad, and when GHC fails to optimise this performance We've managed to minimise the behaviour to the following reproducer (that ignores state entirely), consisting of two files. It depends on `criterion` `Lib.hs`: {{{#!hs {-# LANGUAGE BangPatterns #-} module Lib where -- A type to take the place of state data X a = X { runX :: !a } test1 :: Int -> Int test1 = \(!i) -> go i where go = \(!i) -> if i > 0 then go $! i - 1 else i {-# NOINLINE test1 #-} test2 :: Int -> Int test2 = \(!i) -> runX (go i) where go = \(!i) -> if i > 0 then go $! i - 1 else X i {-# NOINLINE test2 #-} }}} `Main.hs`: {{{#!hs {-# LANGUAGE Strict #-} module Main where import Lib import Criterion import Criterion.Main main :: IO () main = defaultMain [ bgroup "main" [ bgroup "small" [ bench "without state" $ whnf test1 100000000 , bench "with state" $ whnf test2 100000000 ] ] ] }}} Run as above, the code takes twice as long to execute `test2` as it does `test1`. However, when the signature for `runX` is changed to `runX :: !Int`, the code in `test2` exhibits identical performance to `test1`. It has been reproduced across multiple linux64 machines, but not tested on any other architecture or operating system. Please find the full (stack - yes, I know) project as an attachment. You can simply `stack run` to observe the issue. If you have any further queries please let me know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15274: Numerous validation failures when building GHC with LLVM
by GHC 23 Dec '18

23 Dec '18

#15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The CircleCI x86_64/Linux LLVM way exhibits numerous testsuite failures: {{{ TEST="ClosedFam1TH T10508_api T10828 T10891 T11341 T11345 T11463 T11721_TH T11797 T12403 T12478_1 T12646 T12962 T13642 T13887 T14060 T1835 T2222 T2552 T2700 T3920 T4135 T4188 T5037 T5358 T5362 T5363 T5559 T680 T7477 T8761 T8884 T8953 T9064 T9262 T9692 TH_PromotedList TH_RichKinds TH_RichKinds2 TH_Roles3 TH_TyInstWhere2 TH_foreignCallingConventions TH_reifyDecl1 TH_reifyDecl2 TH_reifyInstances TH_repGuard TH_repPrim TH_repPrim2 TH_repUnboxedTuples posix002 prof-doc-fib prof-doc-last profinline001 prog001 scc001 scc002 scc003 scc005" }}} Unfortunately, most of these appear to be segmentation faults and similar, suggesting miscompilation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 22 Dec '18

22 Dec '18

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 #13939 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Comment (by bgamari): I have opened #16084 to track the issue of link speed on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16083: objcpp-hi test appears to be broken on Mojave builder
by GHC 22 Dec '18

22 Dec '18

#16083: objcpp-hi test appears to be broken on Mojave builder --------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- It appears that something has changed in the Darwin toolchain such that `<iostream>` is no longer found by default: {{{ cd "driver/recomp001/recomp001.run" && $MAKE -s --no-print-directory recomp001 Compile failed (exit code 1) errors were: warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found] objcpp-hi.mm:2:9: error: fatal error: 'iostream' file not found #import <iostream> ^~~~~~~~~~ 1 warning and 1 error generated. `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for objcpp-hi(normal) }}} Marking as broken. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11534: Allow class associated types to reference functional dependencies
by GHC 22 Dec '18

22 Dec '18

#11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs class Foo i j | i -> j where type Bar i :: * type Bar i = j }}} This is rejected as `j` is not an argument to `Bar`, but when we realize any instance `j` will be a known type, determined by `i`, as told to us by the | i -> j functional dependency on the class. This would likely require some sort of extra pass over the instances with class associated types of this form to elaborate them, or a slight modification of the default signature implementation for class associated types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11534> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #15147: Type checker plugin receives Wanteds that are not completely unflattened
by GHC 21 Dec '18

21 Dec '18

#15147: Type checker plugin receives Wanteds that are not completely unflattened -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (Type checker) | Keywords: type checker | Operating System: Unknown/Multiple plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the following, a plugin will receive a wanted constraint that includes a `fsk` flattening skolem. {{{ -- "Reduced" via the plugin type family F u v where {} type family G a b where {} data D p where DC :: (p ~ F x (G () ())) => D p }}} (Please ignore the apparent ambiguity regarding `x`; the goal is for the plugin to eliminate any ambiguity.) A do-nothing plugin that merely logs its inputs gives the following for the ambiguity check on DC. {{{ given [G] $d~_a4oh {0}:: (p_a4o2[sk:2] :: *) ~ (p_a4o2[sk:2] :: *) (CDictCan) [G] $d~~_a4oi {0}:: (p_a4o2[sk:2] :: *) ~~ (p_a4o2[sk:2] :: *) (CDictCan) [G] co_a4od {0}:: (G () () :: *) ~# (fsk_a4oc[fsk:0] :: *) (CFunEqCan) [G] co_a4of {0}:: (F x_a4o3[sk:2] fsk_a4oc[fsk:0] :: *) ~# (fsk_a4oe[fsk:0] :: *) (CFunEqCan) [G] co_a4og {1}:: (fsk_a4oe[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CTyEqCan) derived wanted [WD] hole{co_a4or} {3}:: (F x_a4o6[tau:2] fsk_a4oc[fsk:0] :: *) ~# (p_a4o2[sk:2] :: *) (CNonCanonical) untouchables [fsk_a4oe[fsk:0], fsk_a4oc[fsk:0], x_a4o3[sk:2], p_a4o2[sk:2]] }}} Note the `fsk_a4oc[fsk:0]` tyvar in the Wanted constraint, which is why I'm opening this ticket. Its presence contradicts the "The wanteds will be unflattened and zonked" claim from https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Callingpluginsfro… section. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8949: switch -msse2 to be on by default
by GHC 21 Dec '18

21 Dec '18

#8949: switch -msse2 to be on by default ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.9 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: ----------------------------------------------+---------------------------- I propose msse2 to be on by default. I guess the default was chosen way back, when Pentium III support was still relevant. Nowadays we don't really win on the CPU support, because e.g. https://github.com/tibbe/hashable/blob/master/hashable.cabal is built by default with sse2 on the injected C code level. And hashable has a lot of reverse depends, therefore on an end user system (RedHat or Debian) the user is most probably unlucky with a Pentium III CPU anyways. Flipping this default would also fix the excess precision problem for most users of GHC on the i686 platform. GHC should provide a -mno-sse2 flag for the cases when this needs to be disabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #16081: Clean up family instance consistency checking
by GHC 21 Dec '18

21 Dec '18

#16081: Clean up family instance consistency checking -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is a big mess concerning consistency checking for family instances. It's described in `Note [The type family instance consistency story]` in `FamInst`, which is reproduced below. Note in particular the "four subtle points that have not been addressed yet". The fourth one bit me today, and forced me to introduce a new hack into `loadIface`, described in `Note [Loading your own hi-boot file]` in `LoadIface`. Somehow we should be able to do better! {{{ {- Note [The type family instance consistency story] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To preserve type safety we must ensure that for any given module, all the type family instances used either in that module or in any module it directly or indirectly imports are consistent. For example, consider module F where type family F a module A where import F( F ) type instance F Int = Bool f :: F Int -> Bool f x = x module B where import F( F ) type instance F Int = Char g :: Char -> F Int g x = x module Bad where import A( f ) import B( g ) bad :: Char -> Int bad c = f (g c) Even though module Bad never mentions the type family F at all, by combining the functions f and g that were type checked in contradictory type family instance environments, the function bad is able to coerce from one type to another. So when we type check Bad we must verify that the type family instances defined in module A are consistent with those defined in module B. How do we ensure that we maintain the necessary consistency? * Call a module which defines at least one type family instance a "family instance module". This flag `mi_finsts` is recorded in the interface file. * For every module we calculate the set of all of its direct and indirect dependencies that are family instance modules. This list `dep_finsts` is also recorded in the interface file so we can compute this list for a module from the lists for its direct dependencies. * When type checking a module M we check consistency of all the type family instances that are either provided by its `dep_finsts` or defined in the module M itself. This is a pairwise check, i.e., for every pair of instances we must check that they are consistent. - For family instances coming from `dep_finsts`, this is checked in checkFamInstConsistency, called from tcRnImports. See Note [Checking family instance consistency] for details on this check (and in particular how we avoid having to do all these checks for every module we compile). - That leaves checking the family instances defined in M itself against instances defined in either M or its `dep_finsts`. This is checked in `tcExtendLocalFamInstEnv'. There are four subtle points in this scheme which have not been addressed yet. * We have checked consistency of the family instances *defined* by M or its imports, but this is not by definition the same thing as the family instances *used* by M or its imports. Specifically, we need to ensure when we use a type family instance while compiling M that this instance was really defined from either M or one of its imports, rather than being an instance that we happened to know about from reading an interface file in the course of compiling an unrelated module. Otherwise, we'll end up with no record of the fact that M depends on this family instance and type safety will be compromised. See #13102. * It can also happen that M uses a function defined in another module which is not transitively imported by M. Examples include the desugaring of various overloaded constructs, and references inserted by Template Haskell splices. If that function's definition makes use of type family instances which are not checked against those visible from M, type safety can again be compromised. See #13251. * When a module C imports a boot module B.hs-boot, we check that C's type family instances are compatible with those visible from B.hs-boot. However, C will eventually be linked against a different module B.hs, which might define additional type family instances which are inconsistent with C's. This can also lead to loss of type safety. See #9562. * The call to checkFamConsistency for imported functions occurs very early (in tcRnImports) and that causes problems if the imported instances use type declared in the module being compiled. See Note [Loading your own hi-boot file] in LoadIface. -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16014: Avoid unnecessary code duplication from String Literals.
by GHC 21 Dec '18

21 Dec '18

#16014: Avoid unnecessary code duplication from String Literals. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When we compile a function like this: {{{ foo :: Int -> String foo 1 = "1_String" foo 2 = "2_String" foo 3 = "3_String" foo 4 = "4_String" foo 5 = "5_String" foo _ = "unknown_string" }}} We get a few things. Obviously there are the actual strings: {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} Foo.foo10 :: GHC.Prim.Addr# Foo.foo10 = "1_String"# }}} There is no way around these so that's fine. Then we end up with a function to unpack the actual string. {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} Foo.foo9 :: [Char] [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] Foo.foo9 = GHC.CString.unpackCString# Foo.foo10 }}} We want to have a closure for each of these. Otherwise we end up constructing a new string each time, which would be a waste. So on the surface this is fine. However we end up with one of these for each string. Looking at the Cmm/Asm the functions are not THAT small. {{{ [Foo.foo9_entry() // [R1] { info_tbls: [(c2hj, label: Foo.foo9_info rep: HeapRep static { Thunk } srt: Nothing)] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2hj: // global if ((Sp + -16) < SpLim) (likely: False) goto c2hk; else goto c2hl; c2hk: // global R1 = R1; call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8; c2hl: // global (_c2hg::I64) = call "ccall" arg hints: [PtrHint, PtrHint] result hints: [PtrHint] newCAF(BaseReg, R1); if (_c2hg::I64 == 0) goto c2hi; else goto c2hh; c2hi: // global call (I64[R1])() args: 8, res: 0, upd: 8; c2hh: // global I64[Sp - 16] = stg_bh_upd_frame_info; I64[Sp - 8] = _c2hg::I64; R2 = Foo.foo10_bytes; Sp = Sp - 16; call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24; } } }}} In actual code size (HEAD/-O2) the code + info table is about 100Byte. To give an idea in my current ghc-stage2 I have 12,409 calls to unpackCString, and I assume 99% of them are from actual strings. So that comes out to about one megabyte. Out of a binary size of 84MB, so surprisingly significant actually! == Now what can we do about this! I think the right way to go here is to define a `unpackString` function which does the actual work. Then we jump into that from a small per-string wrapper. So we would end up with code like: {{{ [Foo.foo9_entry() // [R1] c2hj: // R1 = Closure pointer R2 = Foo.foo10_bytes; call (unpackString)(R1,R2) args: 8, res: 0, upd: 8; } }}} Which should be well under 50 bytes. It does cause an extra indirection when unpacking the String, but if the performance of that matters using String is likely the wrong choice to begin with. How to actually get GHC to generate code like that I'm not sure yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types
by GHC 21 Dec '18

21 Dec '18

#15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds #-} module A where data family D :: k type family F (a :: k) :: * type instance F (D Int) = Int type instance F (f a b) = Char type instance F (D Int Bool) = Char }}} The last equation, even though a specialization of the middle one, trips up the equality consistency check: {{{#!hs a.hs:9:15: error: Conflicting family instance declarations: F (D Int) = Int -- Defined at a.hs:9:15 F (D Int Bool) = Char -- Defined at a.hs:10:15 | 9 | type instance F (D Int) = Int | ^ }}} So GHC is able to infer that `D Int ~/~ f a b` because `D ~/~ f a`, but for some reason the same reasoning doesn't work for `D ~/~ D a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11