[GHC] #11161: New exhaustiveness checker breaks concurrent/prog001
#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: concurrent/prog001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #10711) leads me to believe that this patch is to blame. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: gkaracha (added) * owner: => gkaracha Old description:
The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #10711) leads me to believe that this patch is to blame.
New description: The new exhaustiveness checker appears to allocate until the machine runs out of memory while compiling the `concurrent/prog001` testcase. In particular it stalls while desugaring the `Thread` module. The fact that this module contains non-trivial pattern matching, coupled with the compiler gets stuck in `Desugar`, and the fact that I've noted other performance issues with the new exhaustiveness checker (see #11160) leads me to believe that this patch is to blame. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George Karachalias <george.karachalias@…>): In [changeset:"ae4398d64655b43606386dddb01637bbfcf0171e/ghc" ae4398d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae4398d64655b43606386dddb01637bbfcf0171e" Improve performance for PM check on literals (Fixes #11160 and #11161) Two changes: 1. Instead of generating constraints of the form (x ~ e) (as we do in the paper), generate constraints of the form (e ~ e). The term oracle (`tmOracle` in deSugar/TmOracle.hs) is not really efficient and in the presence of many (x ~ e) constraints behaves quadratically. For literals, constraints of the form (False ~ (x ~ lit)) are pretty common, so if we start with { y ~ False, y ~ (x ~ lit) } we end up givng to the solver (a) twice as many constraints as we need and (b) half of them trigger the solver's weakness. This fixes #11160. 2. Treat two overloaded literals that look different as different. This is not entirely correct but it is what both the previous and the current check did. I had the ambitious plan to do the *right thing* (equality between overloaded literals is undecidable in the general case) and just use this assumption when issuing the warnings. It seems to generate much more constraints than I expected (breaks #11161) so I just do it immediately now instead of generating everything and filtering afterwards. Even if it is not (strictly speaking) correct, we have the following: * Gives the "expected" warnings (the ones Ocaml or the previous algorithm would give) and, * Most importantly, it is safe. Unless a catch-all clause exists, a match against literals is always non-exhaustive. So, effectively this affects only what is shown to the user (and, evidently, performance!). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: gkaracha => * keywords: => PatternMatchWarnings * status: closed => new * resolution: fixed => Comment: Re-opening to improve for 8.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
#11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11161#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler
participants (1)
-
GHC