- ghc-tickets - Haskell.org

[GHC] #13692: Constructors and such should be able to move around seq# sometimes
by GHC 15 May '17

15 May '17

#13692: Constructors and such should be able to move around seq# sometimes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc2 Keywords: | 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: -------------------------------------+------------------------------------- This code {{{#!hs module SeqCon where import Control.Exception (evaluate) blah :: Int -> IO Int blah x = (+2) <$> evaluate (x + 3) }}} compiled with `-O2 -ddump-prep -dsuppress-coercions` produces the following (and `-ddump-stg` doesn't change much of note): {{{ SeqCon.blah1 :: GHC.Types.Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=<L,1*U(U)><S,U>, Unf=OtherCon []] SeqCon.blah1 = \ (x_s1cz [Occ=Once!] :: GHC.Types.Int) (s_s1cA [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { sat_s1cE [Occ=Once] :: GHC.Types.Int [LclId] sat_s1cE = case x_s1cz of { GHC.Types.I# x1_s1cC [Occ=Once] -> case GHC.Prim.+# x1_s1cC 3# of sat_s1cD { __DEFAULT -> GHC.Types.I# sat_s1cD } } } in case GHC.Prim.seq# @ GHC.Types.Int @ GHC.Prim.RealWorld sat_s1cE s_s1cA of { (# ipv_s1cG [Occ=Once], ipv1_s1cH [Occ=Once!] #) -> let { sat_s1cL [Occ=Once] :: GHC.Types.Int [LclId] sat_s1cL = case ipv1_s1cH of { GHC.Types.I# x1_s1cJ [Occ=Once] -> case GHC.Prim.+# x1_s1cJ 2# of sat_s1cK { __DEFAULT -> GHC.Types.I# sat_s1cK } } } in (# ipv_s1cG, sat_s1cL #) } -- RHS size: {terms: 5, types: 3, coercions: 5, joins: 0/0} SeqCon.blah :: GHC.Types.Int -> GHC.Types.IO GHC.Types.Int [GblId, Arity=2, Caf=NoCafRefs, Str=<L,1*U(U)><S,U>, Unf=OtherCon []] SeqCon.blah = (\ (eta_B2 [Occ=Once] :: GHC.Types.Int) (eta_B1 [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> SeqCon.blah1 eta_B2 eta_B1) `cast` <Co:5> }}} This builds a closure to build an `Int` and passes it to `seq#`. That seems a bit wasteful, since we don't actually need the `Int` box. I think what we'd really like to end up with is something like {{{#!hs blah1 = \ (x :: Int) (s :: State# RealWorld) -> case seq# x s of { (# s', x' #) -> case x' of { I# x# -> (# s', I# (x# +# 5#) #) }} }}} Here's one vague idea: when we analyse `x+3` (the argument to `seq#`) under a strict demand, we see it is strict in `x`. So we can transform `seq# (x + 3) s` into {{{#!hs case seq# x s of (# s', x' #) -> seq# (x' + 3) s' }}} We know that `x'` is in WHNF, so we should (I think) be able to see that `x' + 3` isn't bottom, so we can use {{{#!hs case seq# x s of {(# s', x' #) -> case x' + 3 of {!res -> s', res}} }}} Side note: the redundant eta-expansion in `blah` is a bit surprising. `blah1` already has arity 2, so I'd have expected `blah` to just coerce it directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 15 May '17

15 May '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): simonpj: I've added two examples that use IO. After a bit of work I managed to make a big improvement on `x2n1`: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- bspt -0.1% +0.1% 0.007 0.007 0.0% cacheprof -0.1% +0.1% +28.4% +28.4% +0.9% grep -0.1% -0.2% 0.000 0.000 0.0% maillist -0.1% -0.3% 0.053 0.053 0.0% hpg -0.1% -0.4% 0.205 0.205 0.0% pic -0.1% -0.6% 0.007 0.007 0.0% compress2 +0.2% -0.9% 0.196 0.196 -19.2% infer -0.1% -1.2% 0.069 0.069 0.0% sphere -0.1% -1.7% 0.049 0.049 0.0% solid -0.1% -6.6% 0.127 0.169 0.0% x2n1 -0.1% -84.7% 0.006 0.006 0.0% -------------------------------------------------------------------------------- Min -0.1% -84.7% -37.7% -35.7% -19.2% Max +0.2% +0.1% +34.3% +34.2% +0.9% Geometric Mean -0.1% -1.9% -2.6% -1.3% -0.2% }}} I wonder if this improvement justifies the added complexity to the compiler (about 400 lines of code added under `compiler/`). Right now I don't see any way to make the analysis/transformation more effective. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:73> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints
by GHC 15 May '17

15 May '17

#7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | 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 bgamari): We don't currently offer a way to view the runtime representation of a type at runtime (other than I suppose `Generic`). That being said, we do generate Typeable evidence for promoted data constructors, so we already do much of the work necessary to do so. That being said, it's not clear that this would be a useful enough feature to justify the cost. As far as making the hash more precise is concerned, the data family issue is enough of am argument against rocking the boat without very good reason. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7897#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints
by GHC 14 May '17

14 May '17

#7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | 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 cdupont): I have a real use case for this bug in Hint: https://github.com/mvdan/hint/issues/31 Having proper fingerprints would allow to check the run time type representation and prevent the segfault. Is there a workaround? How to check the structure of a type at run-time? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7897#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches)
by GHC 14 May '17

14 May '17

#13696: rts/linker/ElfTypes.h does not compile on most of UNREG arches (and some registerised arches) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Builds fail as: {{{ rts_dist_HC rts/dist/build/RtsStartup.o rts/linker/ElfTypes.h:23:4: error: error: #error "Unsupported arch!" }}} The code that fails in '''rts/linker/ElfTypes.h''': {{{#!c # define ELF_TARGET_AMD64 /* Used inside <elf.h> on Solaris 11 */ #if defined(powerpc64_HOST_ARCH) || defined(powerpc64le_HOST_ARCH) \ || defined(ia64_HOST_ARCH) || defined(aarch64_HOST_ARCH) \ || defined(x86_64_HOST_ARCH) # define ELF_64BIT #elif defined(sparc_HOST_ARCH) || defined(i386_HOST_ARCH) \ || defined(arm_HOST_ARCH) # define ELF_32BIT #else # error "Unsupported arch!" #endif }}} Note it's a whitelist of architectures. It fails at least on '''powerpc''' (arm_HOST_ARCH), '''hppa'' (hppa_HOST_ARCH), '''m68k''' (m68k_HOST_ARCH). '''mips''', '''mips64''', '''alpha''', '''s390x''', '''sparc64'''. It does not look like keeping a whitelist is scalable here. How about using {{{#!c #if defined(__LP64__) || defined (_LP64) }}} as a proxy for ELF64 and maintain a list of arches that are exception instead? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #605: Optimisation: strict enumerations
by GHC 14 May '17

14 May '17

#605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/605#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12600: Overloaded method causes insufficient specialization
by GHC 13 May '17

13 May '17

#12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 `foo` function in the following code does not get specialized completely by `ghc -O2`, even though all the overloaded functions in the module are marked `INLINE`. Specifically, it gets compiled into a call to a function with an `Eq Int` dictionary passed at runtime. {{{#!hs module Foo where class Eq1 f where eq1 :: (Eq a) => f a -> f a -> Bool data F a = F !a !a data G f a = G !(f a) !(f a) instance Eq1 F where eq1 = \(F a b) (F c d) -> -- In order to reproduce the problem, the body of this function needs to be -- large enough to prevent GHC from voluntarily inlining it. larger $ larger $ larger $ larger $ larger $ larger $ a == c && b == d {-# INLINE eq1 #-} larger :: a -> a larger = id {-# NOINLINE larger #-} instance (Eq1 f) => Eq1 (G f) where eq1 = \(G a b) (G c d) -> eq1 a c && eq1 b d {-# INLINE eq1 #-} foo :: G F Int -> G F Int -> Bool foo a b = eq1 a b }}} Looking at the dumps, it looks like there may be a problem is the specializer. It creates a specialization of `eq1` with the type `(Eq a) => G F a -> G F a -> Bool` rather than the fully-specialized type: `G F Int -> G F Int -> Bool` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13346: Run nofib with -fspec-constr-keen
by GHC 13 May '17

13 May '17

#13346: Run nofib with -fspec-constr-keen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Per Ben Gamari's comment on https://phabricator.haskell.org/D3186, we should try running `nofib` with `-fspec-constr-keen`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13346> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13693: RTS cannot be reinitialized reliably after hs_exit()
by GHC 13 May '17

13 May '17

#13693: RTS cannot be reinitialized reliably after hs_exit() -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 6.10.1 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: -------------------------------------+------------------------------------- #2863 added the FFI spec violation to the docs, but as far as I can tell, there is and was no ticket to actually fix the problems, which seem to be: 1. If the runtime is deinitialized by an `hs_exit()` matching the ''first'' `hs_init()`, then it cannot be reinitialized reliably using `hs_init()`. 2. This condition is not detected, and leads to unpredictable behavior. I'll add a link to ''this'' ticket to the user's guide; even if the ticket is ultimately closed as `WONTFIX`, it will be good to have a persistent reference. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11272: Overloaded state-monadic function is not specialised
by GHC 13 May '17

13 May '17

#11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | 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: -------------------------------------+------------------------------------- I have a simple typeclass-polymorphic function which fails to specialise. Here is module A which defines the function `overloaded`: {{{#!hs module A where import Control.Monad.Trans.State import Control.Monad overloaded :: Ord a => a -> a -> State () () overloaded x y = do () <- get when (x <= y) (overloaded y x) }}} In module B I use `overloaded` on `Int`s: {{{#!hs module B where import A import Control.Monad.Trans.State specialised :: Int -> Int -> () specialised x y = execState (A.overloaded x y) () }}} Unfortunately the generated code is not specialised but passes an `Ord` dictionary around. It doesn't make any difference if I mark `overloaded` as `INLINEABLE` or not. In the core file, `overloaded` has been worker-wrapper transformed but the worker is marked `INLINEABLE[0]` - so I'm not sure why it's not being specialised. Curiously, if I make `overloaded` be a normal function instead of one in the state monad, or if I replace `() <- get` with simply `get`, specialisation goes through fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11