April 2017 - ghc-tickets

[GHC] #13226: Compiler allocation regressions from top-level string literal patch
by GHC 15 Aug '17

15 Aug '17

#13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 leads to compiler allocation regressions in T12425 and T13035 when those tests are compiled with `-O2`. I took a look at T13035 tonight. `-v` reveals more terms and types. Interestingly, it appears that virtually all the string literals arise from the derived `Typeable` instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13260: panic on unboxed string literal in pattern
by GHC 15 Aug '17

15 Aug '17

#13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- I don't think this program is meaningful, but it shouldn't cause a panic. {{{#!hs {-# LANGUAGE MagicHash #-} g y = case y of "a"# -> True _ -> False }}} {{{ [1 of 1] Compiling CaseOnString ( x/CaseOnString.hs, x/CaseOnString.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): litValue "a"# }}} The panic is also in at least 7.8, 7.10, and HEAD. `"a"#` has type `Addr#`, and I suppose that if we allow `case` on `Addr#` then it ought to use pointer equality. But the literal `"a"#` has no particular address, so matching against it in a `case` doesn't make sense. So I think we should just disallow unboxed string literals as patterns. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13317: exprIsConApp_maybe should deal better with strings
by GHC 15 Aug '17

15 Aug '17

#13317: exprIsConApp_maybe should deal better with strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Consider {{{ x :: Addr# x = "foo"# y = case unpackCString# x of [] -> ... (x:xs) -> ... }}} `exprIsConApp_maybe` has a special case for literal strings; see `Note [exprIsConApp_maybe on literal strings]` in `CoreSubst`. But it only works if `unpackCString#` is applied to a literal, not to a variable bound to a literal (like `x`). The fix is easy. Instead of this code {{{ , [Lit (MachStr str)] <- args = dealWithStringLiteral fun str co }}} we want to use `exprIsLiteral_maybe`, thus {{{ , Just (MachStr str) <- exprIsLiteral_maybe ... arg = dealWithStringLiteral fun str co }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13344: Core string literal patch regresses compiler performance considerably
by GHC 15 Aug '17

15 Aug '17

#13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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 Core string literals patch regresses compiler performance by nearly 5%. https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53… We should really understand why this is; this is a huge regression for something that really shouldn't be costly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0
by GHC 15 Aug '17

15 Aug '17

#13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Phab:D1259, which teaches the compiler to aggressively float-out string literals during desugaring, regresses compiler allocations on `T1969` by 15% or so at -O0`. = The problem = In the case of `T1969` (compiled with `-O0`) the difference is quite stark: with floating the non-optimizing simplifier pass produces `{terms: 16,893, types: 7,552, coercions: 0, joins: 0/0}`, without it produces `{terms: 12,693, types: 4,552, coercions: 0, joins: 0/0}`. The (minimized) test looks like, {{{#!hs module T1969 where class C a where c :: a -> String d :: a -> String d x = c x e :: a -> String e x = c x data A1 = A1 instance C A1 where c A1 = "A1" }}} == Post-desugar == The reason for the regression is in part due to the fact that we float out the `unpackCString# "An"` expression. That is, after desugaring without floating we get (looking at just the `A1` bindings), {{{#!hs T1969.$dme :: forall a. C a => a -> String T1969.$dme = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM3 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM3 -- same as $dme T1969.$dmd :: forall a. C a => a -> String T1969.$dmd = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM2 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM2 $cc_a1i7 :: A1 -> String $cc_a1i7= \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } Rec { T1969.$fCA3 :: C A3 T1969.$fCA3 = T1969.C:C @ A3 $cc_a1hl $cd_a1hp $ce_a1hy $ce_a1hy :: A3 -> String $ce_a1hy = T1969.$dme @ A3 T1969.$fCA3 $cd_a1hp :: A3 -> String $cd_a1hp = T1969.$dmd @ A3 T1969.$fCA3 end Rec } }}} Whereas with floating we get, {{{#!hs -- same as above T1969.$dme :: forall a. C a => a -> String T1969.$dmd :: forall a. C a => a -> String ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } Rec { T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik $ce_a1ik :: A1 -> String $ce_a1ik = T1969.$dme @ A1 T1969.$fCA1 $cd_a1ib :: A1 -> String $cd_a1ib = T1969.$dmd @ A1 T1969.$fCA1 end Rec } }}} So far things aren't so bad: the only interesting difference is the floated `[Char]`, which we would expect. However, let's then see what happens during simplification. == Post-simplification == Without floating we see, {{{#!hs T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cc_a1i7 $cc_a1i7 $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } }}} Whereas with floating we have, {{{#!hs ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } $cd_a1ib :: A1 -> String $cd_a1ib = \ (x_aM2 :: A1) -> case x_aM2 of { A1 -> ds_d1k4 } $ce_a1ik :: A1 -> String $ce_a1ik = \ (x_aM3 :: A1) -> case x_aM3 of { A1 -> ds_d1k4 } T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik }}} This is quite interesting: without floating we are somehow able to collapse each of the `A1 -> String` bindings into a single binding (despite CSE being disabled due to `-O0`!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10809: Add prefetch{Small}{Mutable}Array[0..3]#
by GHC 15 Aug '17

15 Aug '17

#10809: Add prefetch{Small}{Mutable}Array[0..3]# -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We now have a number of prefetch operations: {{{ prefetchAddr0# prefetchMutableByteArray0# prefetchAddr1# prefetchMutableByteArray1# prefetchAddr2# prefetchMutableByteArray2# prefetchAddr3# prefetchMutableByteArray3# prefetchByteArray0# prefetchValue0# prefetchByteArray1# prefetchValue1# prefetchByteArray2# prefetchValue2# prefetchByteArray3# prefetchValue3# }}} but we are missing variants for fetching slots of a `{Small}{Mutable}Array#`. This differs from fetching the item pointed to by the entry at that address, so `prefetchValueX` does us no good there. Basically this just needs to compute the offset of the appropriate slot and prefetch the memory for that portion of the array as an address like we do indexing into a byte array. I have some code that could benefit a fair bit from being able to prefetch a binary search on array elements this way, when storing those elements either in a traditional sorted order or Eytzinger layout. I've verified this experimentally by unsafeCoercing existing bytearray primitives to make them work on other array types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration
by GHC 15 Aug '17

15 Aug '17

#12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Old code: {{{#!hs data Full :: Type -> Type data AST :: (Type -> Type) -> (Type -> Type) -- ASTF :: (Type -> Type) -> (Type -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- New code with richer kinds {{{#!hs data Sig a = Full a | a :-> Sig a data AST :: (Sig a -> Type) -> (Sig a -> Type) data Sig a = Full a | a :-> Sig a -- ASTF :: (Sig a -> Type) -> (a -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Sig Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} As the type of `ASTF` hints at it could accept arguments of kind `Sig a -> Type` and `a`. I would like to reference the variable `a` from the kind of `Domain` in the kind of `Internal`, but this fails: {{{#!hs -- • Kind variable ‘u’ is implicitly bound in datatype -- ‘Internal’, but does not appear as the kind of any -- of its type variables. Perhaps you meant -- to bind it (with TypeInType) explicitly somewhere? -- Type variables with inferred kinds: a -- • In the class declaration for ‘Syntactic’ class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- Should the `u` in the kind of `Domain a` be quantified over (which makes this compile)? {{{#!hs type Domain a :: forall k. Sig k -> Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13364: Remove checkValidTelescope
by GHC 15 Aug '17

15 Aug '17

#13364: Remove checkValidTelescope -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- All of this new `TypeInType` nonsense has provided a number of ways that we can arrive at ill-scoped kinds. Let's assume we have {{{ data SameKind :: k -> k -> Type }}} and then here are three subtly ill-scoped kinds: {{{ forall a (b :: a) (c :: Proxy d). SameKind b d forall a. forall (b :: a). forall (c :: Proxy d). SameKind b d forall d. forall a (b :: a). SameKind b d }}} Despite the close similarity between these cases, they are all handled separately. See `Note [Bad telescopes]` in !TcValidity for an overview, but these are spread between `tcImplicitTKBndrsX`, `tcExplicitTKBndrsX`, and those functions' calls to `checkValidTelescope`, `checkZonkValidTelescope`, and `checkValidInferredKinds`. While I am unaware of a concrete bug this all causes, it's a mess. Better would be to use the existing machinery to prevent skolem-escape: `TcLevel`s and implication constraints. Specifically, it's quite plausible that all this can be avoided by a simple rule: bump the `TcLevel` (and create an implication constraint) for ''every'' new type variable brought into scope (including implicitly). (Actually, implicit variables have an implicit ordering that GHC is free to decide, so all implicitly bound variables should be brought into scope at once, with just one bump in the `TcLevel`.) It might all just work! And then we can delete gobs of hairy code. Hooray! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12931: tc_infer_args does not set in-scope set correctly
by GHC 15 Aug '17

15 Aug '17

#12931: tc_infer_args does not set in-scope set correctly -------------------------------------+------------------------------------- Reporter: johnleo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12549 #11371 | #12785 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As noted in https://ghc.haskell.org/trac/ghc/ticket/12785#comment:6, `TcHsType.tc_infer_args` does not set its in-scope set correctly, which means the call to `TcMType.new_meta_tv_x` will fail if `substTyUnchecked` is replaced by `substTy` in the line {{{ kind = substTyUnchecked subst (tyVarKind tv) }}} This is the only known caller of `new_meta_tv_x` to not set the in-scope set, now that #12549 has been fixed. Once this bug is fixed, change `substTyUnchecked` back to `substTy` in the line noted above. Note that other calls to `substTyUnchecked` that need to be converted to `substTy` are covered in the general ticket #11371. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13615: Wrong results from what supposed to be pure function with presense of parallel evaluation
by GHC 09 Aug '17

09 Aug '17

#13615: Wrong results from what supposed to be pure function with presense of parallel evaluation -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mostly self contained sample - only depends on base, deepseq and locally provided hashable and unordered-containers. No unsafePtrEq involved, but unsafeThaw/Freese is - affected function uses `foldl'` to insert stuff into hashmap - I don't think there's a way to obtain multiple references to the same map. Making arguments strict or rnf'ing them doesn't help. Issue is reproduceable with HEAD with -O0 but not with O2. in ghc 8.0.2 and 7.10.1 it's reproduceable with -O2 as well. {{{ sum (map snd xs) = map snd (toList $ fromListWith (+) xs) }}} ^ this statement fails to hold when xs contains stuff with memocombinators and parallel evaluation from evaluation strategies I found which inplace update needs to be replaced with copy and update to make things work - bug is fixed after changing unsafeInsertWith, BitmapIndexed branch: {{{ - A.unsafeUpdateM ary i st' - return t + let ary' = A.update ary i st' + return $ BitmapIndexed b ary' }}} Steps: clone this: {{{ https://github.com/pacak/cuddly-bassoon }}} {{{ stack build }}} {{{ ./.stack-work/install/x86_64-linux/ghc-8.0.2/8.0.2/bin/gamebooksolver- solvebook02 }}} Last command will either finish successfully printing `"solving\n0.0"` or will die with `error` in `src/Solver.hs` `regroup` function. To reproduce the problem computer must have at least 3 CPUs, running with +RTS -N1 or -N2 "fixes" the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 57