December 2014 - ghc-tickets

Re: [GHC] #3064: Very long compile times with type functions
by GHC 31 Dec '14

31 Dec '14

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Good points in comment:21. I'm especially swayed by the ease with which this regression can be avoided, whereas previous problems were not. I do think, once a decision is made regarding 7.10 vs 7.12, a release note should be added. And, if possible, an error message that includes a note whenever the strictly-decreasing-superclass criterion bites would also be great. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 30 Dec '14

30 Dec '14

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, for the evaluation-depth thing, I think that all that is necessary is: * Call `bumpSubGoalDepth` on the `fe_loc` field of `fmode` in `try_to_reduce` in `TcFlatten.flatten_exact_fam_app_fully`. * And call `subGoalDepthExceeded` in the same function. Or the depth-exceeded check could be in `flatten_one`. Might you do this? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3064: Very long compile times with type functions
by GHC 30 Dec '14

30 Dec '14

#3064: Very long compile times with type functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler (Type | Version: 6.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T3064 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It may be "a little disappointing" but nevertheless I think it's a notable step forward: * It eliminates a tricky and hard-to-explain complication in the implementation. * It fixes a substantial performance regression that affects programs with deeply-nested superclasses, affecting both compile time and run time. * It eliminates a collection of regressions, whereby silent superclasses actually cause some programs to fail unexpectedly, for very hard-to- explain reasons. They are listed in the commit message. * Moreover, there is no good workaround if you actually hit those regressions. In contrast, there is an immediate and easy workaround if you hit the new regression. * None of this bites you unless you are sailing close to the wind (`UndecidableInstances`). As to whether this belongs in 7.10 I am agnostic. The performance improvements will help everyone slightly (especially in monad-transformer- heavy code). The behaviour change is there all right, but will affect very few people. I don't feel strongly either way. I am not arguing to push it into 7.10, but I will not argue against doing so either. Does anyone else have a view? The default decision is "no" because it is a change wrt RC1. Incidentally, you say "in perverse but realistic scenarios, might cause the superclass dictionary to loop". Indeed it is realistic. It would be all too easy to add by accident {{{ instance (UserOfRegs r CmmExpr) => UserOfRegs r CmmReg where ... }}} perhaps even in another module. Guarding against such subtle loops is a very good thing, in my view. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3064#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 30 Dec '14

30 Dec '14

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for having an evaluation depth. But I'm cautious about adding a flag. Just saying "lazier" doesn't say much. If we could somehow promise "lazy", for some well-specified meaning of that term, then I'd go for that. But not "disable some implementation optimisation that happens to allow one program (that one one cares about) to typecheck". Currently we flatten type-function applications, and reduce them aggressively. I think it's pretty odd that `id2` typechecks with the optimisation disabled; I strongly suspect that a simple variant will not. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 29 Dec '14

29 Dec '14

#7788: Recursive type family causes <<loop>> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): Here's what I'm worried about here. This function is clearly very innocent: {{{ id :: a -> a id x = x }}} It compiles, obviously, without complaint. But, with 7.10, the following doesn't: {{{ type family F a where F a = F a id2 :: F a -> F a id2 x = x }}} This is slightly disturbing because `id2` is merely a specialization of `id`. I think there is an easy solution here, though: allow users to disable the optimisation that we've put into !TcFlatten (`try_to_reduce`). If a user says `-flazier-type-families`, then we turn off the optimization. Most type-family-heavy programs will simply compile much more slowly... but a few will compile in finite time that didn't previously. As a separate solution here, we probably should also detect when we're looping while evaluating a type family by tracking evaluation depth. I'd much rather get an error saying we've blown a limited stack size than to just loop. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9847: Remove "Difficulty" field from the Trac
by GHC 29 Dec '14

29 Dec '14

#9847: Remove "Difficulty" field from the Trac -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When we recently discussed the [[Newcomers]] page on ghc-devs (this thread: https://www.haskell.org/pipermail/ghc- devs/2014-November/007297.html) we ended up with a conclusion that the "Difficulty" field is not very useful. Simon Marlow proposed that we should remove it: https://www.haskell.org/pipermail/ghc- devs/2014-November/007455.html I agree with Simon's opinion - we don't need Difficulty if we have Keywords. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 29 Dec '14

29 Dec '14

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Changes (by hvr): * milestone: 7.12.1 => 7.10.1 Comment: btw, I noticed that the API exposed by GHC.RTS.Flags varies depending on `unsigned int`: {{{#!hs -- | @'nat'@ defined in @rts/Types.h@ type Nat = #{type unsigned int} data GCFlags = GCFlags { statsFile :: Maybe FilePath , giveStats :: GiveGCStats , maxStkSize :: Nat , initialStkSize :: Nat , stkChunkSize :: Nat ... }}} Is this really a good idea rather simply using `Word` which I assume should always be large enough to contain the range of `CULong`? Moreover, shouldn't most of those small-fields be `!`-ed to avoid thunks and unecessary pointer chasing? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5364: Access RTS flag values from inside Haskell programs
by GHC 29 Dec '14

29 Dec '14

#5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D306 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"40561cd235f07d41904d2604ff7f0c942af4d35e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="40561cd235f07d41904d2604ff7f0c942af4d35e" Fix `heapSizeSuggesionAuto` typo (#9934) This was introduced in 1617a10a (re #5364) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5364#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5910: Holes with other constraints
by GHC 27 Dec '14

27 Dec '14

#5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.5 Component: Compiler | Keywords: holes (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: high => normal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5910#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery
by GHC 27 Dec '14

27 Dec '14

#9067: Optimize clearNursery by short-circuiting when we get to currentNursery ------------------------------+-------------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- This is a note to myself so I don't forget about this. Essentially, we can do something like this (this particular patch variant untested): {{{ diff --git a/rts/sm/Storage.c b/rts/sm/Storage.c index 36776b9..0311042 100644 --- a/rts/sm/Storage.c +++ b/rts/sm/Storage.c @@ -598,6 +598,11 @@ clearNursery (Capability *cap) ASSERT(bd->gen_no == 0); ASSERT(bd->gen == g0); IF_DEBUG(sanity,memset(bd->start, 0xaa, BLOCK_SIZE)); + if (bd == cap->r.rCurrentNursery) { + IF_DEBUG(sanity, for (bd = bd->link; bd; bd = bd->link) + ASSERT(bd->free == bd->start)); + break; + } } } } }}} This is due to invariants about how we manage the currentNursery pointer. But we need a note about it, and I need to test it more carefully. This optimization probably doesn't help too much on normal GHC, but when I have lots of nurseries it helps quite a bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9067> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4