January 2018 - ghc-tickets

[GHC] #14630: name shadowing warnings by record pattern synonyms + RecordWildCards or NamedFieldPuns
by GHC 31 Jan '18

31 Jan '18

#14630: name shadowing warnings by record pattern synonyms + RecordWildCards or NamedFieldPuns -------------------------------------+------------------------------------- Reporter: | Owner: (none) mizunashi_mana | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I use PatternSynonyms + RecordWildCards/NamedFieldPuns, I get name shadowing warnings. I am hoping that these warnings don't trigger in the below case. {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE NamedFieldPuns #-} module TestPatternSynonyms where pattern Tuple :: a -> b -> (a, b) pattern Tuple{x, y} = (x, y) {-# COMPLETE Tuple #-} f :: (a, b) -> a f Tuple{x} = x {- warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding -} g :: (Int, Int) -> Int g Tuple{..} = x + y {- warning: [-Wname-shadowing] This binding for ‘x’ shadows the existing binding This binding for ‘y’ shadows the existing binding -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14746: Provide PDEP and PEXT instructions
by GHC 31 Jan '18

31 Jan '18

#14746: Provide PDEP and PEXT instructions -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The PDEP (parallel bit deposit) and PEXT (parallel bit extract) instructions are super cool and could be very naturally expressed in GHC as: {{{ packedBitDeposit :: Word# -> Word# -> Word# packedBitExtract :: Word# -> Word# -> Word# }}} I requesting that these be added to GHC.Prim (or more accurately, I'm requesting approval for these be added to GHC.Prim, by me or by any other interested party, possibly at a more distant point in the future). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14746> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > Did you recompile all the libraries, or just nofib? Just nofib. > Can you see what is happening with the 5% allocation increase in mate? Sure, I'll update. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > These are -O vs -O + late-dmd-anal I assume. It'd be worth doing the same with -O2 vis -O2 + late-dmd-anal nofib runs with -O2 by default. Here's an example command that nofib runs to compile of the benchmarks: {{{ ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -c Main.hs -o Main.o }}} with `-flate-dmd-anal`: {{{ ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -flate-dmd-anal -rtsopts -c Main.hs -o Main.o }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. * These are `-O` vs `-O + late-dmd-anal` I assume. It'd be worth doing the same with `-O2` vis `-O2 + late-dmd-anal` * Did you recompile all the libraries, or just nofib? * A 4.6% increase in compiler allocations and compile time. * We get some small wins. * Can you see what is happening with the 5% allocation increase in `mate`? * I think that HEAD has indeed abandoned the "clever .hi file scheme", so we don't need to worry about that part. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I've attached the nofib-analyse output. For reference, here's the wiki page on late demand analysis: https://ghc.haskell.org/trac/ghc/wiki/LateDmd. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "analyse" added. nofib using GHC HEAD, compare default with -flate-dmd-anal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14745: Functional dependency conflicts in givens
by GHC 31 Jan '18

31 Jan '18

#14745: Functional dependency conflicts in givens -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this {{{ {-# LANGUAGE FlexibleContexts, MultiParamTypeClasses, FunctionalDependencies #-} module FunDep where class C a b c | a -> b c instance C Int Bool Char f :: (C Int b c) => a -> c f = undefined }}} When doing the ambiguity check we effectively ask whether this would typecheck {{{ g :: (C Int b c) => a -> c g = f }}} We instantiate `f`'s type, and try to solve from `g`'s type signature. So we end up with {{{ [G] d1: C Int b c [W] d2: C Int beta c }}} Now, from the fundeps we get {{{ Interact d1 with the instance: [D] b ~ Bool, [D] c ~ Char Ineract d2 with the instance: [D] beta ~ Bool, [D] c ~ Char Interact d1 with d2 [D] beta ~ b }}} What is annoying is that if we unify `beta := b`, we can solve the [W] constraint from [G], leaving only [D] constraints which we don't even always report (see discussion on #12466). But if, randomly, we instead unify `beta := Bool`, we get an insoluble constraint `[W] C Int Bool c`, which we report. So whether or not typechecking succeeds is rather random; very unsatisfactory. What is really wrong? Well, that Given constraint `(C Int b c)` is in conflict with the top-level instance decl. Maybe we should fail if that happens? But see #12466... and `Note [Given errors]` in `TcErrors`. The test program in Trac #13651 is just like this, only with type functions rather than type classes. I'm not sure what to do, but I'm leaving this ticket as a record that all is not well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hang on. So late-dmd-anal may make no difference in this particular, but I bet it makes a difference sometimes. And if so we should switch it on for -02. Could you do a nofib run with and without late-dmd-anal, to see? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6087: Join points need strictness analysis
by GHC 31 Jan '18

31 Jan '18

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): GHC 8.2.2 does not generate such `Int` allocations with `-O2`. `-flate- dmd-anal` makes no difference in `possibleMoves` output. I think we can close this as fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0