October 2015 - ghc-tickets

[GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build
by GHC 29 Oct '18

29 Oct '18

#9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Takano Akio's [https://github.com/takano-akio/ww-fusion worker-wrapper fusion] modifies `foldr/build` fairly conservatively to allow safe fusion of `foldl` and friends without relying on arity analysis. This advantage is important for two reasons that I know of: 1. As discussed in Joachim Breitner's original paper, the current arity analysis is unable to infer arity correctly when facing certain forms of recursion. 2. The current arity analysis, and probably ''any'' practical arity analysis, depends on inlining to a degree that can sometimes be unhealthy. I would love to make functions like `hPutStr` fuse, but I suspect doing so safely at present would likely cause a code explosion—the function being folded is too large to want to inline to make it available for arity analysis following fusion. I don't understand it completely yet, but it looks like `foldrW/buildW` can eliminate a lot of this uncertainty. Furthermore, it appears that functions currently written using `foldr` in a "right-handed" way can remain unchanged, using an implementation of `foldr` in terms of `foldrW`. Only "left-handed" folds will need to be rewritten to take advantage of this framework, along with all the `build`s. That said, `foldrW/buildW` probably has its weaknesses too. The basic fusion rule looks like this. {{{#!hs {-# RULES "foldrW/buildW" forall f z (i :: Wrap f b) (g :: forall c g . (Wrap g c) -> (a -> c -> c) -> c -> c) . foldrW i f z (buildW g) = g i f z #-} }}} If `g` and `i` are not inlined sufficiently to merge with each other, I imagine this could produce worse results than `foldr/build` when the latter works properly. The only way to really get a feel for performance would be to carefully modify everything to work as well as it can with this framework and see how the results compare. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9374: Investigate Static Argument Transformation
by GHC 29 Oct '18

29 Oct '18

#9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with `-fstatic-argument-transformation`. The comment in DynFlags says: {{{ Max writes: I think it's probably best not to enable SAT with -O2 for the 6.10 release. The version of SAT in HEAD at the moment doesn't incorporate several improvements to the heuristics, and I'm concerned that without those changes SAT will interfere with some attempts to write "high performance Haskell", as we saw in some posts on Haskell-Cafe earlier this year. In particular, the version in HEAD lacks the tail call criterion, so many things that look like reasonable loops will be turned into functions with extra (unneccesary) thunk creation. }}} 6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #9163: Ptr should have a phantom role
by GHC 28 Oct '18

28 Oct '18

#9163: Ptr should have a phantom role ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In `GHC.Ptr` we see {{{ type role Ptr representational data Ptr a = Ptr Addr# deriving (Eq, Ord) }}} with no comments. Why is `Ptr` representational? In the same module we have `castPtr`: {{{ castPtr :: Ptr a -> Ptr b castPtr (Ptr addr) = Ptr addr }}} which unpacks and repacks a `Ptr`. If `Ptr` was phantom, we could use `coerce`. And that in turn would actually make a lot of code more efficient – there are lots of calls to `castPtr`. Specifically, in `nofib`, I tried implementing `castPtr` with `unsafeCoerce`. Then I found: * 12% less allocation in `reverse-complem` * 7.3% less allocation in `fasta`. * Binary sizes fell 0.1%. Both these benchmarks are ones that do a ''lot'' of I/O, and it turns out that `GHC.IO.Handle.Text.$wa1` has a `castPtr` that (all by itself) accounts for 12% of `reverse-complem`'s total allocation! So making `castPtr` free is good. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10353: Haddock for Data.List should list instances
by GHC 26 Oct '18

26 Oct '18

#10353: Haddock for Data.List should list instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to know the set of classes for which there are instances for `[]`. So, I naturally looked in the documentation for `Data.List`. However, because `Data.List` doesn't export `[]`, this list isn't there. Can this be fixed? (It's an honest question -- because of `[]`'s special syntax, I could see this fix being non-trivial.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10353> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10453: \case should trigger auto-multiline mode in ghci
by GHC 24 Oct '18

24 Oct '18

#10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In ghci, most block heralds trigger the multiline mode when :set +m is on. However, \case does not (and should). Compare: {{{ Prelude> ($True) (\case Prelude| x -> x Prelude| ) True Prelude> ($True) $ \case <interactive>:11:11: Empty list of alternatives in case expression Use EmptyCase to allow this }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by GHC 13 Oct '18

13 Oct '18

#8763: forM_ [1..N] does not get fused (10 times slower than go function) ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Apparently idiomatic code like {{{forM_ [1.._N]}}} does not get fused away. This can give serious performance problems when unnoticed. {{{ -- Slow: forM_ [0.._N-1] $ \i -> do ... -- Around 10 times faster: loop _N $ \i -> do ... {-# INLINE loop #-} loop :: (Monad m) => Int -> (Int -> m ()) -> m () loop bex f = go 0 where go !n | n == bex = return () | otherwise = f n >> go (n+1) }}} Full code example: https://gist.github.com/nh2/8905997 - the relevant alternatives are commented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 86

[GHC] #10783: Partial type signatures should work with pattern synonym signatures
by GHC 10 Oct '18

10 Oct '18

#10783: Partial type signatures should work with pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern MyJust :: _ pattern MyJust a = Just a }}} GHC can correctly infer the type for the pattern without the type signature so (to me) it is unexpected that this inferred type is not reported to me when using partial type signatures. It just seems to not be implemented currently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10783> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8708: Kind annotation in tuple not parsed
by GHC 04 Oct '18

04 Oct '18

#8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Consider this: {{{ {-# LANGUAGE KindSignatures #-} foo :: (Int, Int :: *) foo = undefined }}} HEAD reports {{{ /Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’ }}} Changing the line to {{{ foo :: (Int, (Int :: *)) }}} fixes the problem. Note the extra parentheses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9136: Constant folding in Core could be better
by GHC 03 Oct '18

03 Oct '18

#9136: Constant folding in Core could be better ------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Constant folding in Core is still a bit feeble. For example, when staring at the code for `nofib/shootout/k-nucleotide` I saw this expression: {{{ (x +# 8) -# 1 }}} which would be relatively easy to optimise. The difficulty is knowing where to stop. What about `(8 +# x) -# 1`? Anyway, this ticket is to record the issue. Currently constant folding is done by the built-in RULES in `compiler/prelude/PrelRules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #10791: Add a --disable-large-memory-space configure option
by GHC 02 Oct '18

02 Oct '18

#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature | Status: new request | Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- GHC recently started using large (1TB) address space on 64 bit systems. This feature is enabled by default but does not work on arm64-linux or amd64-solaris. Even just for testing, it would be nice to be able to disable this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6