February 2014 - ghc-tickets

[GHC] #8429: GHC.Base.{breakpoint, breakpointCond} do nothing
by GHC 12 Feb '14

12 Feb '14

#8429: GHC.Base.{breakpoint, breakpointCond} do nothing ------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 1377 | ------------------------------------+------------------------------------- The `GHC.Exts` module exports functions [[http://hackage.haskell.org/package/base-4.6.0.1/docs/GHC- Exts.html#g:6|breakpoint and breakpointCond]]. Right now they are no-ops, but apparently at some point in the past could be used to set breakpoints programmatically. From my reading of the source code, this feature was removed (either accidentally or on purpose) when the implementation of breakpoints [[changeset:cdce647711c0f46f5799b24de087622cb77e647f/ghc|was reworked]]. Relevant commits: * 31751ccacc24ebe5d15a0af84b10dc612d455440 * 3a99fa889bdff0c86df20cb18c71d30e30a79b43 * cdce647711c0f46f5799b24de087622cb77e647f Initially reported [http://stackoverflow.com/questions/19283911/how-do-i -use-ghc-exts-breakpoint here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8429> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 11 Feb '14

11 Feb '14

#2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8767 -------------------------------------+------------------------------------ Changes (by nomeata): * status: patch => closed * resolution: => fixed * related: => #8767 Comment: Ok, pushed in patches {{{ git log b4715d67^...cde88e20 }}} Patch f4fb94f3 has a small improvement of compiler performance as a side- effect (which I did not investigate further). The ask of actually adding such rules is tracked in #8767. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2110#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 11 Feb '14

11 Feb '14

#2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"377672ae068f6dbfa0354dfab95f41bdd26b0df4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="377672ae068f6dbfa0354dfab95f41bdd26b0df4" Test case for RULE map coerce = coerce (This tests #2110.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2110#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 11 Feb '14

11 Feb '14

#2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by Joachim Breitner <mail@…>): In [changeset:"b4715d67ae90f4cc847daa94f0fc056a40057d65/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b4715d67ae90f4cc847daa94f0fc056a40057d65" Replace forall'ed Coercible by ~R# in RULES we want a rule "map coerce = coerce" to match the core generated for "map Age" (this is #2110). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2110#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2110: Rules to eliminate casted id's
by GHC 11 Feb '14

11 Feb '14

#2110: Rules to eliminate casted id's -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by nomeata): I changed the definition of `coerce` back to the naive one, and aimed at making the rule matcher smarter. I did this by adding a function `exprIsLambda_maybe` which is used when a rule template contains a lambda. Previously, the code would either use a Lambda, if its there, or eta- expand both sides otherwise. The latter seemed to be somewhat dangerous (could waste work, although I could not produce a example for that due to later CSE and other effects), and did not help in the case discussed here. So instead I try to „make the expression“ into a lambda. Either it already is a lambda, or it is a (nested) application of something that has a currently active unfolding which is unsaturated: In that case, unfold it, `simpleOptExpr` and recursively look for further lambdas. Any any cast occurring while doing so will be pushed inside the lambda. With that change, matching `unsafeCoerce` works as well! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2110#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking
by GHC 11 Feb '14

11 Feb '14

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Difficult (2-5 warning at compile-time | days) Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by jkarni): * cc: jkarni@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/595#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 10 Feb '14

10 Feb '14

#7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Tracing this back I found the `Note [Dealing with bottom]` in `CoreArity`, where the arity of case branches is used to calculate the arity of a case. Quote: > We ignore this "problem" (unless -fpedantic-bottoms is on), because being scrupulous would lose an important transformation for many programs. (See Trac #5587 for an example.) So the next step would be answering: Can we distinguish between cases where this dodgy optimization is useful and required, and cases where it hurts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 10 Feb '14

10 Feb '14

#7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): Ah, interesting. The problem is not `mkIdDot2` (that has Arity 1 allright), the problem is `unIdDot2`, which suddenly as artiy 2! {{{ T7542.unIdDot2 :: forall a_az8 b_az9. (a_az8 -> T7542.Id b_az9) -> a_az8 -> b_az9 [LclIdX, Arity=2, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=2, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20 0] 50 0}] T7542.unIdDot2 = \ (@ a_aKU) (@ b_aKV) (f_aze :: a_aKU -> T7542.Id b_aKV) (eta_B1 :: a_aKU) -> case f_aze of f_Xzl { __DEFAULT -> T7542.unId @ b_aKV (f_Xzl eta_B1) } }}} (This is already after `InitialPhase [Gentle]`). One would expect `MkId` and `unId` to behave the same... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 10 Feb '14

10 Feb '14

#7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nomeata): @ekmett: Ok, thanks for the input. So clearly it should _not_ be closed then. So what you’d like to see is to have GHC behave here as if `-fpedantic- bottoms` is on always. Obviously, one could make that flag the default, but there must be reasons why it is not the default. What I find surprising: The core generated for {{{ mkIdDot2 :: (a -> b) -> a -> Id b mkIdDot2 f = f `seq` \x -> MkId (f x) }}} is {{{ mkIdDot2 = (λ f. f) |> (some cast involving Id)) }}} which is the same core that we get with `mkIdDot2 = coerce` (hey, no unsafe!), but the latter produces the desired `map2 = map`... hard to see (without knowing the simplifier by heart) where this goes wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7542: GHC doesn't optimize (strict) composition with id
by GHC 10 Feb '14

10 Feb '14

#7542: GHC doesn't optimize (strict) composition with id --------------------------------------------+------------------------------ Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by ekmett): @nomeata: As I understand the situation, the fact that this optimization isn't happening without `-fpedantic-bottoms` means I'm basically stuck using the existing hacks in `lens`. The code in question is set up to `INLINE` in library into user code, and they very likely aren't compiling with that flag! (Unless I'm misunderstanding how and where that gets tracked and applid.) We have 3 cases to consider, the existing unsafeCoerce hack, the naive eta expansion we're getting without `-fpedantic-bottoms`, and the version without the eta expansion we can produce with `-fpedantic-bottoms`. It appears that the first and the third scenarios are now the same, but the difference in performance between the existing unsafeCoerce hack and the eta expanded code can be asymptotic, if this is closed as is, the fix does me no good, and I'll be left using the existing coercions to ensure a good user experience. =/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7542#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0