October 2014 - ghc-tickets

[GHC] #9694: Template Haskell: support other FFI calling conventions
by GHC 20 Oct '14

20 Oct '14

#9694: Template Haskell: support other FFI calling conventions -------------------------------------+------------------------------------- Reporter: mtolly | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In the Template Haskell syntax representations, an [https://hackage.haskell.org/package/template-haskell-2.9.0.0/docs /Language-Haskell-TH-Syntax.html#t:Callconv FFI calling convention] can currently only be CCall or StdCall. I'd like to generate code with [http://weblog.luite.com/wordpress/?p=14 GHCJS JavaScript imports], which use a "javascript" calling convention. The [http://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1550008… FFI section of the Report] mentions other potential conventions, and specifically says that implementations can create new ones as appropriate, so perhaps a new constructor could be added which takes an arbitrary string? Something like: {{{ data Callconv = CCall | StdCall | Callconv String deriving( Show, Eq, Data, Typeable ) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9694> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #6018: Injective type families
by GHC 20 Oct '14

20 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:89 and comment:90 I'm struggling with limited personal bandwidth, and daunted by the challenge of giving a tutorial about the type inference engine, which is one of the most complex parts of GHC. Let me make this offer. If you do the rest, I'll do the bit in the type inference engine that exploits injectivity. It won't take long, and then you can see. Decomposition in brief. If you want `Maybe a ~ Maybe b` then it's enough to prove `a ~ b`. From a proof of the latter we can get a proof of the former. No more than that. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:91> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries
by GHC 20 Oct '14

20 Oct '14

#6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6086#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9561: Clean up mergeSATInfo
by GHC 20 Oct '14

20 Oct '14

#9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `mergeSATInfo` in SAT.hs is much longer and harder to read than it needs to be. I am attaching a patch to make it use `zipWith` instead of zipping manually. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9536: Implement foldr/cons/build
by GHC 20 Oct '14

20 Oct '14

#9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There seem to be various issues with general `fold/cons` and even `cons/build` rules, but it seems pretty clear to me that the simple `fold/cons/build` rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve some other analyses and speed several benchmarks up, including speeding up some things that other fusion changes slowed down. I say "seems to" because I never trust my timings much at all. {{{#!hs {-# RULES "foldr/cons/build" forall c n x (g::forall b. (a->b->b) -> b -> b) . foldr c n (x:build g) = c x (g c n) #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9529: Clean up cseProgram
by GHC 20 Oct '14

20 Oct '14

#9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I think this should be a no-brainer: Replace {{{#!hs cseProgram :: CoreProgram -> CoreProgram cseProgram binds = cseBinds emptyCSEnv binds cseBinds :: CSEnv -> [CoreBind] -> [CoreBind] cseBinds _ [] = [] cseBinds env (b:bs) = (b':bs') where (env1, b') = cseBind env b bs' = cseBinds env1 bs }}} with {{{#!hs cseProgram :: CoreProgram -> CoreProgram cseProgram = snd . mapAccumL cseBind emptyCSEnv }}} I'll attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci
by GHC 20 Oct '14

20 Oct '14

#9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: ghci, strict, | Differential Revisions: memory | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- (http://stackoverflow.com/questions/24838982/memory-blowing-up-for-strict- sum-strict-foldl-in-ghci) Suppose we have {{{ --Test.hs import Data.List longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ takeWhile (< 10000000) longList main = do print $ result }}} If one deletes all the ".hi" and ".o" files and then loads into ghci via : {{{ ghci -fobject-code Test.hs }}} then upon running "main" the memory blows up. However if one first compiles via : {{{ ghc Test.hs }}} and then subsequently loads into ghci via : {{{ ghci Test.hs }}} then upon running "main" the memory does not blow up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9355: scanr does not participate in stream fusion
by GHC 20 Oct '14

20 Oct '14

#9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This should be a no-brainer—it's trivial two write `scanr` as a foldr, making it a good consumer. Wrapping it up in `build` makes it a good producer too, but may require back-and-forth RULES. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9369: Data.List.unfoldr does not fuse and is not inlined.
by GHC 20 Oct '14

20 Oct '14

#9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `Data.List.unfoldr` is not a good producer for foldr/build fusion, and it's not wrapped to enable inlining. I don't know how often people explicitly fold over an unfold, but this of course also affects map and filter. The inlining issue is also serious: inlining `unfoldr` can often allow the `Maybe` to be erased altogether. I'm not sure this fix is perfect, but it seems a lot better than the current situation: {{{#!hs import GHC.Exts (build) {-# NOINLINE [1] unfoldr #-} unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr f b = go b where go b = case f b of Just (a,new_b) -> a : go new_b Nothing -> [] {-# INLINE [0] unfoldrB #-} unfoldrB :: (b -> Maybe (a, b)) -> b -> (a -> c -> c) -> c -> c unfoldrB f b' c n = go b' where go b = case f b of Just (a,new_b) -> a `c` go new_b Nothing -> n {-# RULES "unfoldr" [~1] forall f b . unfoldr f b = build (unfoldrB f b) #-} }}} As a simple example, consider the code {{{#!hs hello :: Double -> Double -> [Double] hello x n = map (* 3) $ L.unfoldr f x where f x | x < n = Just (x, x**1.2) | otherwise = Nothing }}} With `Data.List.unfoldr` and the latest bleeding-edge GHC, this produces {{{#!hs hello1 hello1 = \ ds_d1ZF -> case ds_d1ZF of _ { D# x_a21W -> D# (*## x_a21W 3.0) } $whello $whello = \ w_s266 ww_s26a -> map hello1 (unfoldr (\ x_X1Hx -> case x_X1Hx of wild_a20E { D# x1_a20G -> case tagToEnum# (<## x1_a20G ww_s26a) of _ { False -> Nothing; True -> Just (wild_a20E, D# (**## x1_a20G 1.2)) } }) w_s266) hello hello = \ w_s266 w1_s267 -> case w1_s267 of _ { D# ww1_s26a -> $whello w_s266 ww1_s26a } }}} Using the above implementation (and renaming the function from `hello` to `bye`) yields {{{#!hs $wbye $wbye = \ ww_s25Z ww1_s263 -> letrec { $wgo_s25U $wgo_s25U = \ ww2_s25S -> case tagToEnum# (<## ww2_s25S ww1_s263) of _ { False -> []; True -> : (D# (*## ww2_s25S 3.0)) ($wgo_s25U (**## ww2_s25S 1.2)) }; } in $wgo_s25U ww_s25Z bye bye = \ w_s25V w1_s25W -> case w_s25V of _ { D# ww1_s25Z -> case w1_s25W of _ { D# ww3_s263 -> $wbye ww1_s25Z ww3_s263 } } }}} I don't think there can be any doubt which is better. Yes, some fine tuning may be needed to make the rules apply in all appropriate cases. I don't understand things like the comment on the definition of `map` drawing attention to eta expansion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9398: Data.List.cycle is not a good producer
by GHC 20 Oct '14

20 Oct '14

#9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Data.List.cycle is not a good producer. I'm not at all sure this solution is the best, but it allocates much less when mapped over and then folded. If we could make it a good consumer cheaply that would be nice too, but I imagine it's probably mostly applied to short lists, so that is probably not a priority. {{{#!hs {-# INLINE cycle #-} cycle :: [a] -> [a] cycle [] = error "Prelude.cycle: empty list" cycle xs = concat $ repeat xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22