August 2015 - ghc-tickets

[GHC] #8441: Allow family instances in an hs-boot file
by GHC 03 Sep '18

03 Sep '18

#8441: Allow family instances in an hs-boot file ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling an .hs-boot file with a data instance leads to this error: {{{ Illegal family instance in hs-boot file }}} Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance. Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

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

30 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] #8733: I/O manager causes unnecessary syscalls in send/recv loops
by GHC 27 Aug '18

27 Aug '18

#8733: I/O manager causes unnecessary syscalls in send/recv loops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- Network applications often call send followed by recv, to send a message and then read an answer. This causes syscall traces like this one: {{{ recvfrom(13, ) -- Haskell thread A sendto(13, ) -- Haskell thread A recvfrom(13, ) = -1 EAGAIN -- Haskell thread A epoll_ctl(3, ) -- Haskell thread A (a job for the IO manager) recvfrom(14, ) -- Haskell thread B sendto(14, ) -- Haskell thread B recvfrom(14, ) = -1 EAGAIN -- Haskell thread B epoll_ctl(3, ) -- Haskell thread B (a job for the IO manager) }}} The recvfrom call always fails, as the response from the partner we're communicating with won't be available right after we send the request. We ought to consider descheduling the thread as soon as sending is "done". The hard part is to figure out when that is. See http://www.yesodweb.com/blog/2014/02/new-warp for a real world example. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10346: Cross-module SpecConstr
by GHC 24 Aug '18

24 Aug '18

#10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type-class specialisation now happens flawlessly across modules. That is, if I define {{{ module DefineF where f :: Num a => a -> a {-# INLINEABLE f #-} f x = ...f x'.... }}} then modules that import `DefineF` and call `f` at some particular type (say `Int`) will generate a specialised copy of `f`'s code. But this does not happen for `SpecConstr`; we only specialise a function for calls made in the same module. All the infrastructure is in place to allow cross-module `SpecConstr`; it just hasn't been done yet. This ticket is to record the idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #9688: Improve the interaction between CSE and the join point transformation
by GHC 24 Aug '18

24 Aug '18

#9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: CSE | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It appears that the join point transformation sometimes interferes with CSE when CSE would be much better. Two examples: === digitToIntMaybe === Suppose we define {{{#!hs isHexDigit :: Char -> Bool isHexDigit c = (fromIntegral (ord c - ord '0')::Word) <= 9 || (fromIntegral (ord c - ord 'a')::Word) <= 5 || (fromIntegral (ord c - ord 'A')::Word) <= 5 digitToInt c | (fromIntegral dec::Word) <= 9 = dec | (fromIntegral hexl::Word) <= 5 = hexl + 10 | (fromIntegral hexu::Word) <= 5 = hexu + 10 | otherwise = error ("Char.digitToInt: not a digit " ++ show c) -- sigh where dec = ord c - ord '0' hexl = ord c - ord 'a' hexu = ord c - ord 'A' -- We could also expand this out in cases manually, but it makes no -- difference as far as I can tell. }}} Suppose we then write a naive `digitToIntMaybe` function: {{{#!hs digitToIntMaybe c | isHexDigit c = Just (digitToInt c) | otherwise = Nothing }}} What I would want this to do is "zip" the nested cases and give Core like this: {{{ $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Ag -> let { x#_a2yy x#_a2yy = -# (ord# ww_s2Ag) 48 } in case tagToEnum# (leWord# (int2Word# x#_a2yy) (__word 9)) of _ { False -> let { x#1_X2z7 x#1_X2z7 = -# (ord# ww_s2Ag) 97 } in case tagToEnum# (leWord# (int2Word# x#1_X2z7) (__word 5)) of _ { False -> let { x#2_X2zh x#2_X2zh = -# (ord# ww_s2Ag) 65 } in case tagToEnum# (leWord# (int2Word# x#2_X2zh) (__word 5)) of _ { False -> Nothing; True -> Just (I# (+# x#2_X2zh 10)) }; True -> Just (I# (+# x#1_X2z7 10)) }; True -> Just (I# x#_a2yy) } digitToIntMaybe digitToIntMaybe = \ w_s2Ad -> case w_s2Ad of _ { C# ww1_s2Ag -> $wdigitToIntMaybe ww1_s2Ag } }}} But instead, the join point transformation triggers, and we get this: {{{ digitToIntMaybe1 digitToIntMaybe1 = \ ww_s2Cp -> error (unpackAppendCString# "Char.digitToInt: not a digit "# ($w$cshowsPrec15 ww_s2Cp ([]))) $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Cp -> let { $j_s2Bc $j_s2Bc = \ _ -> Just (let { a_s2B5 a_s2B5 = int2Word# (-# (ord# ww_s2Cp) 48) } in case tagToEnum# (leWord# a_s2B5 (__word 9)) of _ { False -> let { a1_s2B7 a1_s2B7 = int2Word# (-# (ord# ww_s2Cp) 97) } in case tagToEnum# (leWord# a1_s2B7 (__word 5)) of _ { False -> let { a2_s2B9 a2_s2B9 = int2Word# (-# (ord# ww_s2Cp) 65) } in case tagToEnum# (leWord# a2_s2B9 (__word 5)) of _ { False -> digitToIntMaybe1 ww_s2Cp; True -> I# (+# (word2Int# a2_s2B9) 10) }; True -> I# (+# (word2Int# a1_s2B7) 10) }; True -> I# (word2Int# a_s2B5) }) } in case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 48)) (__word 9)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 97)) (__word 5)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 65)) (__word 5)) of _ { False -> Nothing; True -> $j_s2Bc void# }; True -> $j_s2Bc void# }; True -> $j_s2Bc void# } digitToIntMaybe digitToIntMaybe = \ w_s2Cm -> case w_s2Cm of _ { C# ww1_s2Cp -> $wdigitToIntMaybe ww1_s2Cp } }}} We perform the same three tests twice each, and test for an error condition that obviously can't happen. === `quotRem` and `divMod` === If we define {{{#!hs x `quot` y = fst (x `quotRem` y) x `rem` y = snd (x `quotRem` y) }}} and then write something like {{{#!hs f x y | x `rem` y == 0 = x `quot` y | otherwise = 17 }}} then CSE works some magic and we only calculate `quotRem x y` once. Unfortunately, if we do this: {{{#!hs whatever x y = if x `myRem` y == 0 then (x `myQuot` y) + 14 else x `myQuot` y }}} then the join point transformation fires, collecting the `myQuot x y` expressions in the case branches and preventing CSE from recognizing the much better opportunity to eliminate those calculations altogether. The situation with `divMod` is much worse. The join point transformation applied to the cases defining `divMod` prevents CSE from working magic on it in even simple situations, unless one of the arguments is known, making this definition unusable (the resulting Core is too horrifyingly long to paste here). It would probably be possible to improve the `divMod` situation to something close to the `quotRem` one by making `divMod` `NOINLINE` and adding special `divModLit` rules, but I'd much rather see a general solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10100: Bogus "redundant constraint" warning with functional dependencies
by GHC 23 Aug '18

23 Aug '18

#10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this code with GHC HEAD: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} module T10100 where data Zero data Succ a class Add a b ab | a b -> ab, a ab -> b instance Add Zero b b instance (Add a b ab) => Add (Succ a) b (Succ ab) }}} Gives a bogus warning about redundant constraint: {{{ Redundant constraint: Add a b ab In the instance declaration for ‘Add (Succ a) b (Succ ab)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9854: Literal overflow check is too aggressive
by GHC 21 Aug '18

21 Aug '18

#9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The literal overflow check is too aggressive. Sometimes you want to give a literal as a hexadecimal value that does fit inside e.g. an `Int`, like so: {{{ Prelude> 0xdc36d1615b7400a4 :: Int <interactive>:2:1: Warning: Literal 15868100553162883236 is out of the Int range -9223372036854775808..9223372036854775807 -2578643520546668380 }}} However the compiler complains because of the wrap-around. I feel this is common enough and practice (and perfectly well-defined) that the compiler shouldn't warn. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10542: Incorrect Unicode input on Windows Console
by GHC 20 Aug '18

20 Aug '18

#10542: Incorrect Unicode input on Windows Console -------------------------------------+------------------------------------- Reporter: ptroev | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: windows | Operating System: Windows stdin utf-8 cmd chcp 65001 | Type of failure: Incorrect result getLine | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 4471 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- To reproduce: - start a windows console - change the console's font to a ttf unicode font, like "Lucida Console". - type "chcp 65001" to set it to the UTF-8 code page. - start ghci (same error appears when running compiled executable) - > import System.IO (or GHC.IO.Handle) - > enc <- mkTextEncoding "UTF8" - > hSetEncoding stdin enc - > getLine - > Фывфыв (or any international unicode sequence) *** Exception: <stdin>: hGetLine: end of file -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9441: Merge identical top-level expressions following simplification when it is safe to do so
by GHC 19 Aug '18

19 Aug '18

#9441: Merge identical top-level expressions following simplification when it is safe to do so -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I redefine {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} and then write a couple test cases: {{{#!hs appRev xs ys = xs ++ reverse ys revAppRev xs ys = reverse xs ++ reverse ys }}} I end up getting some rather annoying code duplication (lots of stuff omitted from the following): {{{#!hs Rec { poly_go_r2v3 poly_go_r2v3 = \ @ a_a2nF ds_a2zc eta_Xl -> case ds_a2zc of _ { [] -> eta_Xl; : y_a2zh ys_a2zi -> poly_go_r2v3 ys_a2zi (: y_a2zh eta_Xl) } end Rec } reverse reverse = \ @ a_a2nF eta_B1 -> poly_go_r2v3 eta_B1 ([]) Rec { revAppRev2 revAppRev2 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev2 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { revAppRev1 revAppRev1 = \ @ a_a2y7 ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> revAppRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } Rec { appRev1 appRev1 = \ @ a_a2xE ds_a2zc eta_B1 -> case ds_a2zc of _ { [] -> eta_B1; : y_a2zh ys_a2zi -> appRev1 ys_a2zi (: y_a2zh eta_B1) } end Rec } }}} The `reverse` function was inlined three times. In each case, there was no fusion, so `build` was inlined and the resulting copy of the `reverse` worker lifted to the top level. It would seem to me that once simplification is complete, it should be safe to merge all these copies into one. They are all `Rec {\ ... -> ...}` forms, so I don't think this has any potential to introduce undesirable sharing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8944: Warn instead of stopping on misplaced Haddock comments
by GHC 17 Aug '18

17 Aug '18

#8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Given a simple module like {{{ module H where data F = F () -- ^ Comment for first type argument () }}} and trying to run Haddock on it, we'll get back {{{ /tmp/H.hs:4:12: parse error on input ‘(’ }}} The error message is rather sub-par in this scenario. It'd be great if we could instead print a warning saying that a Haddock comment is unexpected in that position and then continue on parsing. Best case scenario would be a more informative message such as “Documenting each constructor argument is not supported” but that might be quite a bit harder. Filing on GHC Trac as it's the parser that needs changing I believe. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8944> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11