- ghc-tickets - Haskell.org

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 19 Mar '18

19 Mar '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by bgamari): I think (1) is the best option given the amount of effort we have available to expend on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types
by GHC 19 Mar '18

19 Mar '18

#13776: -ddump-splices produces unnecessarily qualified names for tuple and list types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH f :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int) f = (1,2) g :: $(conT ''[] `appT` conT ''Int) g = [] }}} You'll get some unsavory output: {{{ Bug.hs:10:8-34: Splicing type conT ''[] `appT` conT ''Int ======> GHC.Types.[] Int Bug.hs:7:8-53: Splicing type conT ''(,) `appT` conT ''Int `appT` conT ''Int ======> GHC.Tuple.(,) Int Int }}} It's unsavory because if you actually try to use the spliced output in Haskell code: {{{#!hs module Bug2 where f :: GHC.Tuple.(,) Int Int f = (1,2) g :: GHC.Types.[] Int g = [] }}} Then it won't parse. Expressions have the same problem: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug3 where import Language.Haskell.TH f :: (Int, Int) f = $(conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1)) g :: [Int] g = $(conE '[]) }}} {{{ Bug3.hs:8:7-65: Splicing expression conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1) ======> (GHC.Tuple.(,) 1) 1 Bug3.hs:11:7-14: Splicing expression conE '[] ======> GHC.Types.[] }}} And patterns: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug4 where import Language.Haskell.TH f :: (Int, Int) -> () f $(conP '(,) [litP (integerL 1), litP (integerL 1)]) = () g :: [Int] -> () g $(conP '[] []) = () }}} {{{ Bug4.hs:8:5-52: Splicing pattern conP '(,) [litP (integerL 1), litP (integerL 1)] ======> GHC.Tuple.(,) 1 1 Bug4.hs:11:5-15: Splicing pattern conP '[] [] ======> GHC.Types.[] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14872: Hex Literals in GHC Core
by GHC 19 Mar '18

19 Mar '18

#14872: Hex Literals in GHC Core -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: lowest | 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: -------------------------------------+------------------------------------- Sometimes, when I'm doing stuff that involves twiddling bits, it would be nicer to see integer literals in hexadecimal when I dump core with `-ddump-simpl`. For example, in a project I'm working on, I've got this: {{{ detectNull :: Word -> Word detectNull x = (x - repeatHexZeroOne) .&. complement x .&. repeatHexEightZero detectArtifact :: Word -> Word -> Word detectArtifact x artifact = detectNull (applyArtifact x artifact) applyArtifact :: Word -> Word -> Word applyArtifact = xor repeatHexZeroOne :: Word repeatHexZeroOne = div maxBound 255 repeatHexEightZero :: Word repeatHexEightZero = 128 * (div maxBound 255 :: Word) }}} Once everything gets unboxed and constant-folding happens, in GHC core, the places where I used `repeatHexZeroOne` show `72340172838076673##` (on a 64-bit machine). This is accurate, but it would be nice I could give a flag to make it show `0x0101010101010101##` instead. This would make it easier for me to confirm that the arithmetic I used to generate a bit pattern actually generated what I thought it did. Admittedly, we'd probably want leading zeroes to get chopped off so that small integer literals didn't show up with 15 zeroes in front of them. So, realistically, it might show up as `0x101010101010101##`. Or maybe it could always to padded with leading zeroes until the length was a power of two. Anyway, not important, but I thought it would be nice to have. Possible flag name: `-ddump-hex-literals`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14872> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14881: Consistent labeling of redundant, qualified imports
by GHC 19 Mar '18

19 Mar '18

#14881: Consistent labeling of redundant, qualified imports -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- {{{ import Data.Map as M (Map, adjust, lookup, fromList) foo :: Map Int Int foo = fromList [] }}} GHC helpfully suggests: {{{ Bug.hs:3:1: warning: [-Wunused-imports] The import of `adjust, M.lookup' from module `Data.Map' is redundant | 3 | import Data.Map as M (Map, adjust, lookup, fromList) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, this message can be improved. Notice that in the line "The import of ...", `adjust` is *not* qualified, while `lookup` *is* qualified. It would be better if this was consistent. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14923: Recompilation avoidance fails after a LANGUAGE change
by GHC 19 Mar '18

19 Mar '18

#14923: Recompilation avoidance fails after a LANGUAGE change -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It looks like the recompilation checker can be confused when a LANGUAGE pragma is added or removed. The following shell script demonstrates the issue: {{{ #!/bin/sh cat >Foo.hs <<END {-# LANGUAGE UndecidableInstances #-} module Foo where END rm -f Foo.hi Foo.o ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag sed -i 's/^{-#/--&/' Foo.hs # comment out the pragma ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag ghc -c Foo.hs; ghc --show-iface Foo.hi | grep flag }}} I get this output: {{{ % ./bug.sh flag hash: b1ada48735eec2ef16d5070887aa7f10 flag hash: b1ada48735eec2ef16d5070887aa7f10 flag hash: e7b294090e04f1a84f0bfc9b8cc49322 compilation IS NOT required flag hash: e7b294090e04f1a84f0bfc9b8cc49322 }}} In the third invocation to GHC, I expect the recompilation checker to detect that compilation is not required, because nothing has changed since the second invocation. Also it seems suspicious that the flag hash changes beteen the second run and the third run. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #3553: parallel gc suffers badly if one thread is descheduled
by GHC 19 Mar '18

19 Mar '18

#3553: parallel gc suffers badly if one thread is descheduled -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2918abf75594001deed51ee252a05b146f844489/ghc" 2918abf7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2918abf75594001deed51ee252a05b146f844489" rts: Add --internal-counters RTS flag and several counters The existing internal counters: * gc_alloc_block_sync * whitehole_spin * gen[g].sync * gen[1].sync are now not shown in the -s report unless --internal-counters is also passed. If --internal-counters is passed we now show the counters above, reformatted, as well as several other counters. In particular, we now count the yieldThread() calls that SpinLocks do as well as their spins. The added counters are: * gc_spin (spin and yield) * mut_spin (spin and yield) * whitehole_threadPaused (spin only) * whitehole_executeMessage (spin only) * whitehole_lockClosure (spin only) * waitForGcThreadsd (spin and yield) As well as the following, which are not SpinLock-like things: * any_work * do_work * scav_find_work See the Note for descriptions of what these counters are. We add busy_wait_nops in these loops along with the counter increment where it was absent. Old internal counters output: ``` gc_alloc_block_sync: 0 whitehole_gc_spin: 0 gen[0].sync: 0 gen[1].sync: 0 ``` New internal counters output: ``` Internal Counters: Spins Yields gc_alloc_block_sync 323 0 gc_spin 9016713 752 mut_spin 57360944 47716 whitehole_gc 0 n/a whitehole_threadPaused 0 n/a whitehole_executeMessage 0 n/a whitehole_lockClosure 0 0 waitForGcThreads 2 415 gen[0].sync 6 0 gen[1].sync 1 0 any_work 2017 no_work 2014 scav_find_work 1004 ``` Test Plan: ./validate Check it builds with #define PROF_SPIN removed from includes/rts/Config.h Reviewers: bgamari, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #3553, #9221 Differential Revision: https://phabricator.haskell.org/D4302 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3553#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14779: Compiling with -g fails -lint-core checks
by GHC 19 Mar '18

19 Mar '18

#14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14122, #14123, | #8472, #14406 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached file produces: {{{ $ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of str_s2UI :: Addr#] The type of this binder is unlifted: str_s2UI Binder's type: Addr# *** Offending Program *** ... str_s2UI :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] str_s2UI = src<Data.Fixed.hs:78:31-39> "MkFixed"# str_a2j4 :: String [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] str_a2j4 = src<Data.Fixed.hs:78:31-39> unpackCString# str_s2UI ... }}} This came up when I wanted to compile GHC HEAD with `-g`. There are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example. I'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope. My HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14779> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #14868: -O -g breaks string literals
by GHC 19 Mar '18

19 Mar '18

#14868: -O -g breaks string literals -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `foo.hs`: {{{#!hs main = print (4, "foo") }}} Compile it and run it like: {{{ % ghc-stage2 -O -g foo.hs % ./foo (4,"\CANq@") }}} Note that the content of the string literal is broken, although the length is preserved. With `-dcore-lint`, the following error is produced: {{{ *** Core Lint errors : in result of Simplifier *** <no location info>: warning: [RHS of ww2_s3hG :: Addr#] Recursive or top-level binder has strict demand info: ww2_s3hG Binder's demand info: <L,U> }}} The offending binding is: {{{#!hs ww2_s3hG :: Addr# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] ww2_s3hG = src<foo.hs:1:18-22> "foo"# }}} Happens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7741: Add SIMD support to x86/x86_64 NCG
by GHC 19 Mar '18

19 Mar '18

#7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Comment (by carter): Ben: what are your current thoughts about how to handle supporting different microarchitectures? 1) Allow generating the instructions but require the application to do cpu detection to avoid bad instructions ? (I’d be fine with that ) Or 2) add micro architecture logic to ghc compilation and have a fall back path? Or 3) some mix of both supported? I’d think near term 1 would be simpler to get working and 3 is what we want to love to -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7741#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5129: "evaluate" optimized away
by GHC 19 Mar '18

19 Mar '18

#5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: seq, evaluate Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13930 | Differential Rev(s): Phab:D615 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"5a1ad231fc871f27f2811ae46285a79573d8dfae/ghc" 5a1ad231/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5a1ad231fc871f27f2811ae46285a79573d8dfae" Update test for #5129: Make sure it runs with --fast validate with correct optimisation settings (-O1 or above) so that it actually tests the bug. Because the bug is in the simplifier running it with -O0 doesn't test it. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5129#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0