August 2018 - ghc-tickets

[GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint`
by GHC 30 Aug '18

30 Aug '18

#15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- {{{#!hs {-# Language DataKinds, TypeInType, TypeFamilies #-} import Data.Kind newtype I a = I a type C = Constraint type family UnitC :: Constraint where UnitC = () instance UnitC => Functor I where fmap = undefined }}} this works fine, but if I try to use the constraint synonym `C` (`UnitC :: C where`) fails with "Instance head is not headed by a class" which has '''no''' Google hits outside of the [https://hackage.haskell.org/package/ghc-8.4.1/docs/src/TcValidity.html#chec… compiler] {{{ $ ghci -ignore-dot-ghci hs/249.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/249.hs, interpreted ) hs/249.hs:13:10: error: • Instance head is not headed by a class • In the instance declaration for ‘Functor I’ | 13 | instance UnitC => Functor I where | ^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15412> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15582: Phabricator shows "drafts" by default
by GHC 30 Aug '18

30 Aug '18

#15582: Phabricator shows "drafts" by default -------------------------------------+------------------------------------- Reporter: monoidal | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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: -------------------------------------+------------------------------------- By default, going to https://phabricator.haskell.org/differential/ shows "Drafts". This category isn't very useful. Is it possible to create a query for "All open" (Statuses: "Any Open Status") and make it the default? I've done this already on my account, but I think it makes sense to do this globally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15580: Specialize min/max functions for GHC provided instances.
by GHC 30 Aug '18

30 Aug '18

#15580: Specialize min/max functions for GHC provided instances. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular for Int/Word/Float/Double we should aim to provide branchless code where reasonable. Especially when using SSE we should just use `minss` instead of {{{ ucomisd %xmm1,%xmm0 jp .Lc5vv jbe .Lc5vw }}} which is worse in all kinds of ways. If someone feels like tackling this I'm happy to help with code review, answering questions, etc. I won't get around to doing it myself any time soon. As a starting point the instance declarations are in ghc- prim/GHC/Classes.hs. I would look into solving this via adding a new MachOP/PrimOP but maybe there are even better ways. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15474: Error message mentions Any
by GHC 30 Aug '18

30 Aug '18

#15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if this is a bug. File: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module T15474 where import Data.Kind (Type) data Proxy a type Forall = forall t. Proxy t f1 :: forall (t :: Type). Proxy t f1 = f1 f2 :: Forall f2 = f1 }}} gives an error message mentioning Any: {{{ • Couldn't match type ‘GHC.Types.Any’ with ‘*’ Expected type: Proxy t Actual type: Proxy t0 }}} The appearance of Any is suspicious - I thought it's an implementation detail? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15474> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8279: bad alignment in code gen yields substantial perf issue
by GHC 29 Aug '18

29 Aug '18

#8279: bad alignment in code gen yields substantial perf issue ------------------------------+-------------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- independently, a number of folks have noticed that in various ways, GHC currently has quite a few different memory alignment related performance problems that can have >= 10% perf impact! Nicolas Frisby notes {{{ On my laptop, a program showed a consistent slowdown with -fdicts-strict I didn't find any obvious causes in the Core differences, so I turned to Intel's Performance Counter Monitor for measurements. After trying a few counters, I eventuall saw that there are about an order of magnitude more misaligned memory loads with -fdicts-strict than without, so I think that may be a significant part of the slowdown. I'm not sure if these are code or data reads. Can anyone suggest how to validate this hypothesis about misaligned reads? A subsequent commit has changed the behavior I was seeing, so I'm not interested in alternatives means to determine if -fdicts-strict is somehow at fault — I'm just asking specifically about data/code memory alignment in GHC and how to diagnose/experiment with it. }}} Reid Barton has independently noted {{{ so I did a nofib run with llvm libraries, ghc quickbuild so there's this really simple benchmark tak, https://github.com/ghc/nofib/blob/master/imaginary/tak/Main.hs it doesn't use any libraries at all in the main loop because the Ints all get unboxed but it's still 8% slower with quick-llvm (vs -fasm) weird right? [14:36:30] <carter> could you post the asm it generates for that function? [14:36:49] <rwbarton> well it's identical between the two versions <rwbarton> but they get linked at different offsets because some llvm sections are different sizes <rwbarton> if I add a 128-byte symbol to the .text section to move it to the same address... then the llvm libs version is just as fast <rwbarton> well, apparently 404000 is good and 403f70 is bad <rwbarton> I guess I can test other alignments easily enough <rwbarton> I imagine it wants to start on a cache line <rwbarton> but I don't know if it's just a coincidence that it worked with the ncg libraries <rwbarton> that it got a good location <rwbarton> for this program every 32-byte aligned address is 10+% faster than any merely 16-byte aligned address <rwbarton> and by alignment I mean alignment of the start of the Haskell code section <carter> haswell, sandybridge, ivy bridge, other? <rwbarton> dunno <rwbarton> I have similar results on Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz <rwbarton> and on Quad-Core AMD Opteron(tm) Processor 2374 HE <carter> ok <rwbarton> trying a patch now that aligns all *_entry symbols to 32 bytes }}} the key point in there is that on the tak benchmark, better alignment for the code made a 10% perf differnce on TAk on Core2 and opteron cpus! benjamin scarlet and Luite are speculating that this may be further induced by Tables next to code (TNC) accidentally creating bad alignment so theres cache line pollution / conflicts between the L1 Instruction- cache and data-caches. So one experiment would be to have the TNC transform pad after the table so the function entry point starts on the next cacheline? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #15555: Finish separating the stable name and stable pointer tables
by GHC 29 Aug '18

29 Aug '18

#15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.4.3 System | 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 stable name table and stable pointer table are both implemented in `rts/Stable.c`, with their code interleaved. As far as I can tell, they basically don't share ''anything''—or at least anything that they actually ''should''. They ''do'' share a mutex, which smells like a terrible idea. Doesn't that just introduce contention between `StableName` and `StablePtr` operations in different threads? They also share an initialization function, `initStableTables`, that appears to allocate both a stable name table and a stable pointer table as soon as either of them is needed. Unless I'm missing something, there's no point whatsoever in doing that. So I think we should actually divide `Stable.c` into `StableName.c` and `StablePtr.c` and give each its own mutex. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #7674: Separate StablePtr table from StableName table.
by GHC 29 Aug '18

29 Aug '18

#7674: Separate StablePtr table from StableName table. -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: fixed | Keywords: rts | stable_ptr stable_name performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer <David.Feuer@…>): In [changeset:"f48e276a5ba68d8b6fcb4a558022581fb30f9326/ghc" f48e276a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f48e276a5ba68d8b6fcb4a558022581fb30f9326" Finish stable split Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7674#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn
by GHC 29 Aug '18

29 Aug '18

#15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Research needed Component: | Version: 8.5 libraries/base | 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: -------------------------------------+------------------------------------- By importing Data.List, we currently get: {{{#!hs sortBy :: (a -> a -> Ordering) -> [a] -> [a] maximumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a minimumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a sortOn :: Ord b => (a -> b) -> [a] -> [a] }}} I believe sortOn to be a very useful 'shortcut'. In that spirit, I propose we add: {{{#!hs maximumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15566> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5945: Lambda lifting
by GHC 28 Aug '18

28 Aug '18

#5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284, #9476 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LateLamLift -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5945#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15568: Kind variables in type family aren't quantified in toposorted order
by GHC 28 Aug '18

28 Aug '18

#15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently, I noticed that an error message I was experiencing differs between GHC 8.4.3 and GHC 8.6.1+. Take this program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy import GHC.Exts (Any) type family F (a :: j) :: k f :: Proxy a -> Proxy (F (a :: j) :: k) f _ = Proxy :: Proxy (Any :: k) }}} On 8.4.3, you'll get: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fprint-explicit-kinds [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:7: error: • Couldn't match type ‘Any k’ with ‘F j k a’ Expected type: Proxy k (F j k a) Actual type: Proxy k (Any k) • In the expression: Proxy :: Proxy (Any :: k) In an equation for ‘f’: f _ = Proxy :: Proxy (Any :: k) • Relevant bindings include f :: Proxy j a -> Proxy k (F j k a) (bound at Bug.hs:11:1) | 11 | f _ = Proxy :: Proxy (Any :: k) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But on 8.6.1 and HEAD, you'll instead get: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs -fprint-explicit-kinds [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:7: error: • Couldn't match type ‘Any k’ with ‘F k j a’ Expected type: Proxy k (F k j a) Actual type: Proxy k (Any k) • In the expression: Proxy :: Proxy (Any :: k) In an equation for ‘f’: f _ = Proxy :: Proxy (Any :: k) • Relevant bindings include f :: Proxy j a -> Proxy k (F k j a) (bound at Bug.hs:11:1) | 11 | f _ = Proxy :: Proxy (Any :: k) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notice that on 8.4.3, it displays `F j k a`, but on 8.6.1, it displays `F k j a`! After some digging, it turns out that this is because on 8.6.1, the order of `F`'s kind variables are quantified completely differently! On 8.4.3, we have: {{{ λ> :kind F F :: forall j k. j -> k }}} But on 8.6.1, we have: {{{ λ> :kind F F :: forall k j. j -> k }}} I would prefer the old behavior of 8.4.3, since `j k` is what you get after performing a left-to-right, reverse topological sort on the kind variables of `F`, which is consistent with how type signatures quantify their type variables. Currently, this quirk doesn't matter that much (except for error messages, as shown above), but if/when visible kind application is implemented, it'll be more noticeable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4