October 2014 - ghc-tickets

[GHC] #9546: filterM is not a good consumer for list fusion
by GHC 01 Oct '14

01 Oct '14

#9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This one shouldn't cause any wonkiness; it just updates `filterM` to fuse is much the same way `mapM` does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9502: mapAccumL does not participate in foldr/build fusion
by GHC 01 Oct '14

01 Oct '14

#9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This can probably be fixed in much the same way as `scanl`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9434: GHC.List.reverse does not fuse
by GHC 01 Oct '14

01 Oct '14

#9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 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: -------------------------------------+------------------------------------- As Edward Kmett speculated could be the case a couple months ago, Joachim Breitner's call arity analysis makes the Prelude version of `reverse` better than GHC's version. It's less clear to me whether it's beneficial to wrap it in `build`, but I think the answer is ''probably'' yes, based on the fact that doing so turns `foldr c n $ reverse xs` into `foldl (flip c) n xs`. {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} This simplifies to {{{#!hs Rec { poly_go_r2uL poly_go_r2uL = \ @ a_a2nn ds_a2xO eta_Xh -> case ds_a2xO of _ { [] -> eta_Xh; : y_a2xT ys_a2xU -> poly_go_r2uL ys_a2xU (: y_a2xT eta_Xh) } end Rec } reverse reverse = \ @ a_a2nn eta_B1 -> poly_go_r2uL eta_B1 ([]) }}} which looks about the same as the current version in GHC.List. Behold the beauty when it is applied to an unfold (with a fusion-friendly version of `unfoldr`): {{{#!hs testReverseUnfoldr f q0 = reverse (unfoldr f q0) }}} simplifies to {{{#!hs testReverseUnfoldr testReverseUnfoldr = \ @ a_a2w3 @ b_a2w4 f_a2mn q0_a2mo -> letrec { go_a1QX go_a1QX = \ b1_a1Hy eta_B1 -> case f_a2mn b1_a1Hy of _ { Nothing -> eta_B1; Just ds_d2d8 -> case ds_d2d8 of _ { (a1_a1Hz, new_b_a1HA) -> go_a1QX new_b_a1HA (: a1_a1Hz eta_B1) } }; } in go_a1QX q0_a2mo ([]) }}} This looks exactly like a hand-written `unfoldl`! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 01 Oct '14

01 Oct '14

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Fuuzetsu, which patch are you talking about, Phab:D175? I don't think it should affect the ABI hash at all, so it only pertains to (2), not (1). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen
by GHC 01 Oct '14

01 Oct '14

#9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Code Coverage | 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: -------------------------------------+------------------------------------- Currently, it's defined {{{#!hs stringify :: String -> String stringify s = reverse . dropWhile isSpace . reverse -- drop trailing space . dropWhile isSpace -- drop leading space . compressSpaces -- replace each span of -- whitespace with a single space $ s where compressSpaces [] = [] compressSpaces (a:as) | isSpace a = ' ' : compressSpaces (dropWhile isSpace as) compressSpaces (a:as) = a : compressSpaces as }}} If we're going to go to the trouble of doing this by hand, we might as well take the efficiency advantage doing so can give us: {{{#!hs stringify :: String -> String -- Spec: stringify = unwords . words stringify xs = go False (dropWhile isSpace xs) where go _haveSpace [] = [] go haveSpace (x:xs) | isSpace x = go True xs | otherwise = if haveSpace then ' ' : x : go False xs else x : go False xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1473: isSpace is too slow
by GHC 01 Oct '14

01 Oct '14

#1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: | Version: 6.6.1 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: hvr, ekmett (added) Comment: I wrote up a whole long comment here, but then TRAC timed me out and I lost it. The gist of it is that I don't think we should be using `iswspace` here at all, because Haskell 2010's [https://www.haskell.org/onlinereport/haskell2010/haskellch16.html specification of `isSpace`] appears to be intended to match [http://www.unicode.org/Public/6.3.0/ucd/PropList.txt the Unicode concept of whitespace], which does not seem to match the locale-specific [http://pubs.opengroup.org/onlinepubs/009695399/functions/iswspace.html definition of `iswspace`]. As I discussed with Carter, we can probably improve the performance of `isSpace` by using something like Yitzchak Gale's implementation modified to cut down the number of branches (since many of them will be mispredicted). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1473#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0