February 2017 - ghc-tickets

[GHC] #13286: Late floating of join points
by GHC 01 Mar '17

01 Mar '17

#13286: Late floating of join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | 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 this, from `GHC.Real`: {{{ GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> joinrec { $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=<S,U><S,U>, Unf=OtherCon []] $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> joinrec { $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# [LclId[JoinId(3)], Arity=3, Str=<S,U><S,U><S,U>, Unf=OtherCon []] $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 }; } in jump $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> jump $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) }; } in jump $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} Note those two `joinrecs`. Neither has any free variables. So we could float them to top level, as ordinary functions, thus {{{ $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} Is this better? * Better before: the nested join points don't allocate a closure; but the top-level defns do build a (never used) closure and slow entry point. * Better after: the externally-visible function might inline more at call sites in other modules. So it's a bit moot. It has something of the flavour of the late lambda- lifting pass. For now I'm doing nothing; just recording the observation. The simple thing is not to float. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13236: Improve floating for join points
by GHC 01 Mar '17

01 Mar '17

#13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having looked at the code in `SetLevels`, am very uncomfortable. My nose tells me that there is far too much chuffing about; it all makes my head spin. '''Question 1'''. Why do we ever "ruin" a join point? See {{{ Note [When to ruin a join point] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Generally, we protect join points zealously. However, there are two situations in which it can pay to promote a join point to a function: 1. If the join point has no value arguments, then floating it outward will make it a *thunk*, not a function, so we might get increased sharing. 2. If we float the join point all the way to the top level, it still won't be allocated, so the cost is much less. Refusing to lose a join point in either of these cases can be disastrous ---for instance, allocation in imaginary/x2n1 *triples* because $w$s^ becomes too big to inline, which prevents Float In from making a particular binding strictly demanded. }}} But I don't agree at all. If we have {{{ let-join j = e in b }}} then we can leave `j` in place as a join point. We can float `e` (via `lvlMFE`) if doing so would increase sharing. Indeed this applies uniformly to all join points. For example {{{ f x = let g y = let-join j z1 z2 = expensive x in case y of A p q -> j p q B r -> j r r C -> True }}} Here it would make sense to float `(expensive x)` out of the `\y` abstrction: {{{ f x = let lvl = expensive x g y = let-join j z1 z2 = lvl in case y of A p q -> j p q B r -> j r r C -> True }}} But doing so does not affect the join point `j`. Nullary join points are no different. This includes floating to the top level. Incidentally the RHS of the join point then becomes tiny, so the join point will be inlined. In short, I think we can just delete all this special code. '''Question 2''': `Note [Join points and MFEs]`. Whe do we ''ever'' float out a MFE that has a free join variable? SLPJ claim: if there is a free join variable, do not float it anywhere. '''Question 3''': Do we actually need to float join points ''at all''? Why? I thik the reason is just to make them small {{{ let-join j1 x = let-join j2 y = y+1 in ... }}} Here perhaps if we float `j2` out of `j1` that might make `j1` small enough to inline. But if that is the only motivation (unlike most of `FloatOut` which is about saving work) we'd better say so loud and clear. And the question is a bit more complicated; e.g. we might want to abstract over Ids to achieve this. e.g. {{{ let-join j1 x = let-join j2 y = x+y in ... ===> let-join j2' x y = x+y j1 x = let-join j2 y = j2' x y in ... }}} Now we can inline `j2`. (The example would be more realistic if the `x+y` was a big expression.) It's not just join parameters; we can abstract over any free variables: {{{ let-join j1 x = let p = x+y in let-join j2 z = p+z in .... }}} Here we could abstract `j2` over `p` in order to float it. It is not clear how best to do this; but I worry that we are asking `FloatOut` to do too much. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13351: Investigate a foldr rule for short static lists
by GHC 28 Feb '17

28 Feb '17

#13351: Investigate a foldr rule for short static lists -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | 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: -------------------------------------+------------------------------------- GHC.Base says: {{{ -- The foldr/cons rule looks nice, but it can give disastrously -- bloated code when commpiling -- array (a,b) [(1,2), (2,2), (3,2), ...very long list... ] -- i.e. when there are very very long literal lists -- So I've disabled it for now. We could have special cases -- for short lists, I suppose. -- "foldr/cons" forall k z x xs. foldr k z (x:xs) = k x (foldr k z xs) "foldr/single" forall k z x. foldr k z [x] = k x z "foldr/nil" forall k z. foldr k z [] = z }}} I wonder if we should extend the list of rules at the bottom to a few more list lengths, as the comment suggests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8779: Exhaustiveness checks for pattern synonyms
by GHC 28 Feb '17

28 Feb '17

#8779: Exhaustiveness checks for pattern synonyms -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Pattern synonyms are great, as they decouple interface from implementation. Especially if #8581 is also implemented, it should be possible to change a type completely while retaining the existing interface. Exciting! Another missing piece is exhaustiveness checks. Given this pattern {{{ initLast [] = Nothing initLast xs = Just (init xs, last xs) pattern xs ::: x <- (initLast -> Just (xs,x)) }}} we want the compiler to tell the programmer that {{{ f [] = ... f (xs ::: x) = ... }}} is complete, while {{{ g (xs ::: x) = ... }}} is not. With view pattern directly, this is impossible. But the programmer did not write view patterns! So here is what I think might work well, inspired by the new `MINIMAL` pragma: We add a new pragma `COMPLETE_PATTERNS` (any ideas for a shorter name). The syntax is essentially the same as for `MINIMAL`, i.e. a boolean formula, with constructors and pattern synonyms as atoms. In this case. {{{ {-# COMPLETE_PATTERNS [] && (:::) #-} }}} Multiple pragmas are obviously combined with `||`, and there is an implicit `{-# COMPLETE_PATTERNS [] && (:) #-}` listing all real data constructors. When checking for exhaustiveness, this would be done before unfolding view patterns, and for `g` above we get a warning that `[]` is not matched. Again, the implementation is very much analogous to `MINIMAL`. Clearly, a library author can mess up and give wrong `COMPLETE_PATTERNS` pragmas. I think that is ok (like with `MINIMAL`), and generally an improvement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 58

[GHC] Trac email verification for user: anubhav94
by GHC 28 Feb '17

28 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=2l51Pn90> Username: anubhav94 Verification Token: 2l51Pn90 -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13294: compactResize is a terrible primop and a terrible name
by GHC 28 Feb '17

28 Feb '17

#13294: compactResize is a terrible primop and a terrible name -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.1 Libraries | 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: -------------------------------------+------------------------------------- compactResize does two things: it changes the default block allocation size of a compact region, and appends a new block to the compact region. There are two problems with this function: first, it's terribly named; it doesn't actually do any resizing of the existing compact region to speak of. Second, there arguably isn't any reason why it should append a new block to the compact region; just let that happen automatically! But I'm not actually using compact regions for anything real. Simon Marlow, do you know why you moved compactResize from Data.Compact.Internal to Data.Compact? If there is some functionality in it that is useful for end users we should articulate it properly. I'm happy to do the docfixes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13249: Default signature check can be quite onerous
by GHC 27 Feb '17

27 Feb '17

#13249: Default signature check can be quite onerous -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #12918 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `bytes` library currently doesn't compile with GHC `master` due to the new check of default signatures (7363d5380e600e2ef868a069d5df6857d9e5c17e, #12918). Consider this example, {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DefaultSignatures #-} module Hi where import Control.Monad.Trans.Class class MonadGet m where type Remaining m :: * remaining :: m (Remaining m) default remaining :: (MonadTrans t, MonadGet n, m ~ t n) => m (Remaining (t m)) remaining = lift remaining }}} Patching this up requires a fair amount of hand-holding, {{{#!hs default remaining :: (MonadTrans t, MonadGet n, m ~ t n, Remaining m ~ Remaining n, Monad n) => m (Remaining m) }}} Yuck. I suppose this is just how the world works, but I thought I'd leave this here in case anyone had a clever idea for improvement. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13070: time after evaluation
by GHC 27 Feb '17

27 Feb '17

#13070: time after evaluation -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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 {{{:set +s}}} gives the time after each evaluation.This time may have a difference of 68% in same calculation.It should not change after each evaluation of computation. Can we have a fixed and real time? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13339: Arbitrarily large expressions built out of cheap primops are not floated out
by GHC 27 Feb '17

27 Feb '17

#13339: Arbitrarily large expressions built out of cheap primops are not floated out -------------------------------------+------------------------------------- Reporter: rwbarton | 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: -------------------------------------+------------------------------------- While investigating #13338 I was tripped up by the fact that GHC won't float out even a large expression like the product in {{{#!hs \i# -> magic# (x# *# 2# *# 2# *# 2# *# 2# *# 2# *# 2# *# 2# *# 2# -# i#) }}} The test involved here is `exprIsCheap`. The fact that `*#` is a cheap primop makes `exprIsCheap` think the whole expression is cheap; but clearly there must come some point where it would be better to float out the expression. Perhaps `exprIsCheap` should work more like `exprIsDupable`, and take the size of the expression into account. See related comments on `primOpIsCheap`, though this ticket is about saving runtime work, not code size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13345: GHC 8 type checker regression
by GHC 27 Feb '17

27 Feb '17

#13345: GHC 8 type checker regression -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: type | Operating System: Unknown/Multiple annotation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.1/2 needs a type annotation where GHC 7.8 can do without: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeSynonymInstances, FlexibleInstances, MultiParamTypeClasses #-} data T = Var | App T T data S = S class Tr a b where tr :: a -> b tr = undefined instance Tr S T where instance Tr a b => Tr [a] [b] where test :: [S] -> T test es = let -- es' :: [T] -- This type annotation is not needed by ghc-7.8 es' = tr es in foldl App Var es' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2