December 2016 - ghc-tickets

[GHC] #9577: String literals are wasting space
by GHC 15 Aug '17

15 Aug '17

#9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- For [https://phabricator.haskell.org/D199 D199] I looked into how string literals are compiled down by GHC. On 64-bit OS X, a simple string `"AAA"` turns into assembly: {{{ .const .align 3 .align 0 c38E_str: .byte 65 .byte 65 .byte 65 .byte 0 }}} (And also something that invokes `unpackCString#`, but that isn't relevant here.) (`MkCore.mkStringExprFS` -> `CmmUtils.mkByteStringCLit` -> `compiler/nativeGen/X86/Ppr.pprSectionHeader`.) Note how this: * Is 8 byte aligned. * Is a `.const` section. I can't find any reason why string literals would need to be 8-byte aligned on OS X. There might be a small benefit in performance to read data starting 8-byte aligned, but I doubt doing that for string literals would be a meaningful difference. Assembly from both clang and gcc does not align string literals. The trivial program: {{{#!hs main :: IO () main = return () }}} has almost 5kB of wasted space of padding between all strings the Prelude brings in, built with GHC HEAD. The fact that it is a `.const` section, instead of `.cstring` (https://developer.apple.com/library/mac/documentation/DeveloperTools/Refere…) means duplicate strings aren't shared by the assembler. GHC floats out string literals to the top-level and uses CSE to eliminate duplicates, but that only works in a single modules. Strings shared between different modules end up as duplicate strings in an executable. The same program as above also has ~4kB of wasted space due to duplicate Prelude strings (`"base"` occurs 16 times!). Compared to the total binary size (4MB after stripping), removing this redundant data wouldn't be a big improvement (0.2%), but I still think it can be a worthwile optimization. I think this can be solved quite easily by creating a new section header for literal strings, which is unaligned and of type `.cstring`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #10922: String inlining is inconsistent
by GHC 15 Aug '17

15 Aug '17

#10922: String inlining is inconsistent -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I have the following code: A.hs: {{{#!hs module A where foo :: String {-# INLINE foo #-} foo = "foo" }}} B.hs: {{{#!hs import A main = if foo == "foo" then return () else putStrLn "Wrong" }}} Compiling this with `-O2` shows the if-statement has not been eliminated (`"Wrong"` is still part of the output with `-ddump-simpl`). However, if I rewrite the code to: A.hs: {{{#!hs module A where foo :: () -> String {-# INLINE foo #-} foo () = "foo" }}} B.hs: {{{#!hs import A main = if foo () == "foo" then return () else putStrLn "Wrong" }}} Then the if-statement disappears and the generated Core has no string literals left. Even when the literal can not be eliminated from B it seems GHC is fine with duplicating it accross two modules if it occurs somewhere inside a function. But once I make it a top-level expression of type `String`, inlining it does not happen. I can not think of how this could be working as intended. (The case where `A.foo` is `""` seems to work differently, but also does not get optimized away.) (This happened to me when rewriting some code that previously used `CPP` for conditional compilation to using `if System.Info.os == "darwin" then ... else ...` and expecting the other OS cases to get optimized away.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality
by GHC 15 Aug '17

15 Aug '17

#12585: GHC duplicates string literals in rodata section and breaks 'Ptr Addr#' equality -------------------------------------+------------------------------------- Reporter: slyfox | 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: -------------------------------------+------------------------------------- {{{#!hs -- test-sha256.hs: {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Prim (Addr#) import GHC.Ptr (Ptr(..), minusPtr) bug :: Addr# -> IO () bug a = do print ("cmp:", Ptr a == Ptr a) print ("delta:", Ptr a `minusPtr` Ptr a) print ("values:", Ptr a, Ptr a) main :: IO () main = bug "Assumptions are subtle!"# }}} {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -O1 --make test-sha256.hs && ./test-sha256 [1 of 1] Compiling Main ( test-sha256.hs, test-sha256.o ) Linking test-sha256 ... ("cmp:",False) ("delta:",-24) ("values:",0x000000000072fdc0,0x000000000072fda8) }}} Stg shows that literal gets inlined: {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -O1 --make test-sha256 -ddump-stg -dsuppress-all -dsuppress-uniques 2>&1 | grep Assumptions eqAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] minusAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] $w$cshowsPrec "Assumptions are subtle!"# w2 $w$cshowsPrec "Assumptions are subtle!"# w2 eqAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] minusAddr# ["Assumptions are subtle!"# "Assumptions are subtle!"#] $w$cshowsPrec "Assumptions are subtle!"# w2 $w$cshowsPrec "Assumptions are subtle!"# w2 }}} I've found this bug as a SIGSEGV on testsuite cryptohash-sha256-0.11.100.1 from hackage. Bytestring assumes that address does not change and implements loops over Ptrs https://github.com/haskell/bytestring/blob/master/Data/ByteString.hs#L1171 : {{{#!hs filter :: (Word8 -> Bool) -> ByteString -> ByteString filter k ps@(PS x s l) | null ps = ps | otherwise = unsafePerformIO $ createAndTrim l $ \p -> withForeignPtr x $ \f -> do t <- go (f `plusPtr` s) p (f `plusPtr` (s + l)) return $! t `minusPtr` p -- actual length where go !f !t !end | f == end = return t | otherwise = do w <- peek f if k w then poke t w >> go (f `plusPtr` 1) (t `plusPtr` 1) end else go (f `plusPtr` 1) t end {-# INLINE filter #-} }}} In case of cryptohash-sha256-0.11.100.1 '''t <- go (f `plusPtr` s) p (f `plusPtr` (s + l))''' for literal inlined righ at 'f' call which caused testsuite failure. It seems sensible not to emit the literal more than once into '''.rodata''' section. It won't guard against problems where literal is exported as a part of .hi file but might be good enough for common cases like this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10809: Add prefetch{Small}{Mutable}Array[0..3]#
by GHC 15 Aug '17

15 Aug '17

#10809: Add prefetch{Small}{Mutable}Array[0..3]# -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonmar Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- We now have a number of prefetch operations: {{{ prefetchAddr0# prefetchMutableByteArray0# prefetchAddr1# prefetchMutableByteArray1# prefetchAddr2# prefetchMutableByteArray2# prefetchAddr3# prefetchMutableByteArray3# prefetchByteArray0# prefetchValue0# prefetchByteArray1# prefetchValue1# prefetchByteArray2# prefetchValue2# prefetchByteArray3# prefetchValue3# }}} but we are missing variants for fetching slots of a `{Small}{Mutable}Array#`. This differs from fetching the item pointed to by the entry at that address, so `prefetchValueX` does us no good there. Basically this just needs to compute the offset of the appropriate slot and prefetch the memory for that portion of the array as an address like we do indexing into a byte array. I have some code that could benefit a fair bit from being able to prefetch a binary search on array elements this way, when storing those elements either in a traditional sorted order or Eytzinger layout. I've verified this experimentally by unsafeCoercing existing bytearray primitives to make them work on other array types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10809> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration
by GHC 15 Aug '17

15 Aug '17

#12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- Old code: {{{#!hs data Full :: Type -> Type data AST :: (Type -> Type) -> (Type -> Type) -- ASTF :: (Type -> Type) -> (Type -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- New code with richer kinds {{{#!hs data Sig a = Full a | a :-> Sig a data AST :: (Sig a -> Type) -> (Sig a -> Type) data Sig a = Full a | a :-> Sig a -- ASTF :: (Sig a -> Type) -> (a -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Sig Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} As the type of `ASTF` hints at it could accept arguments of kind `Sig a -> Type` and `a`. I would like to reference the variable `a` from the kind of `Domain` in the kind of `Internal`, but this fails: {{{#!hs -- • Kind variable ‘u’ is implicitly bound in datatype -- ‘Internal’, but does not appear as the kind of any -- of its type variables. Perhaps you meant -- to bind it (with TypeInType) explicitly somewhere? -- Type variables with inferred kinds: a -- • In the class declaration for ‘Syntactic’ class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- Should the `u` in the kind of `Domain a` be quantified over (which makes this compile)? {{{#!hs type Domain a :: forall k. Sig k -> Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12931: tc_infer_args does not set in-scope set correctly
by GHC 15 Aug '17

15 Aug '17

#12931: tc_infer_args does not set in-scope set correctly -------------------------------------+------------------------------------- Reporter: johnleo | Owner: goldfire 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: #12549 #11371 | #12785 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As noted in https://ghc.haskell.org/trac/ghc/ticket/12785#comment:6, `TcHsType.tc_infer_args` does not set its in-scope set correctly, which means the call to `TcMType.new_meta_tv_x` will fail if `substTyUnchecked` is replaced by `substTy` in the line {{{ kind = substTyUnchecked subst (tyVarKind tv) }}} This is the only known caller of `new_meta_tv_x` to not set the in-scope set, now that #12549 has been fixed. Once this bug is fixed, change `substTyUnchecked` back to `substTy` in the line noted above. Note that other calls to `substTyUnchecked` that need to be converted to `substTy` are covered in the general ticket #11371. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12931> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8147: Exponential behavior in instance resolution on fixpoint-of-sum
by GHC 07 Aug '17

07 Aug '17

#8147: Exponential behavior in instance resolution on fixpoint-of-sum -------------------------+------------------------------------------------- Reporter: | Owner: jkoppel | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: performance, | Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Doing instance resolution on a fixpoint-of-sum type takes a very long time. This is possibly the same issue as issue #5642. These are the numbers I see for various n: {{{ 10 : 0.329s 20 : 0.479s 40 : 0.935s 80 : 2.821s 160 : 11.694s 320 : 1m30.39s 640: Ran for over 1 hour without terminating }}} This uses a couple of attached support files. Apologies for not being able to reduce further. {{{ -- Test.hs {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, UndecidableInstances, OverlappingInstances, TypeOperators, DeriveFunctor, TemplateHaskell #-} module Test where import Control.Monad import Lib import TH {- With n=3, produces data X1 e = X1 e deriving (Functor) data X2 e = X2 e deriving (Functor) data X3 e = X3 e deriving (Functor) type X = X1 :+: X2 :+: X3 -} $(let n = 320 in liftM concat $ sequence [liftM concat $ mapM mkDec $ map (('X':).show) [1..n] , makeSumType "X" (map (('X':).show) [1..n])]) data Y0 e = Y0 e deriving ( Functor ) type X' = Y0 :+: X class Lift f g where lift' :: f (Fix g) -> Fix g instance (Lift f g, Lift f' g) => Lift (f :+: f') g where lift' x = case x of L e -> lift' e R e -> lift' e instance (Functor f, f :<: g) => Lift f g where lift' = In . inj cata :: (Functor f) => (f a -> a) -> Fix f -> a cata f = f . fmap (cata f) . out lift :: Fix X -> Fix X' lift = cata lift' }}} Virtually all the time is spent in compiling lift. For example, with n=640, commenting out lift makes it compile in around 2 seconds. Interestingly, when I add the following code, compilation times only increase by 10-20%. In the original code where I encountered this issue, doing so doubles compilation time. {{{ instance Lift Y0 X where lift' = undefined lower :: Fix X' -> Fix X lower = cata lift' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11196: TypeInType performance regressions
by GHC 07 Aug '17

07 Aug '17

#11196: TypeInType performance regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- This ticket is to track the handful of performance regressions seen with the addition of `TypeInType`. It is quite possibly a good idea to break these out into separate tickets, but until we investigate, they're all bundled here. The regressions are: * T3064, bytes allocated up by 14.9% (will update description) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue
by GHC 02 Aug '17

02 Aug '17

#12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I try to build language-lua as found on Hackage with GHC 8.0.2-rc2 I get the following error. This package works with 8.0.1. I'm using the latest release of cabal-install/Cabal and alex-3.2.1 {{{#!hs src/Language/Lua/Annotated/Lexer.x:149:14: error: • Can't find interface-file declaration for variable AlexTools.runA Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP In the expression: case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } In a case alternative: AlexToken x_a28iK x_a28iL x_a28iM -> case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9522: SPECIALISE pragmas for derived instances
by GHC 01 Aug '17

01 Aug '17

#9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: -------------------------------------+------------------------------------- In package `ghc-prim`, in `GHC.Classes` we have {{{ instance (Eq a) => Eq [a] where {-# SPECIALISE instance Eq [[Char]] #-} {-# SPECIALISE instance Eq [Char] #-} {-# SPECIALISE instance Eq [Int] #-} [] == [] = True (x:xs) == (y:ys) = x == y && xs == ys _xs == _ys = False }}} The `SPECIALISE instance` pragmas instantiate the code for these commonly- used types. But for tuples we use `deriving`: {{{ deriving instance (Eq a, Eq b) => Eq (a, b) }}} and many more similar. There is no way to add a `SPECIALISE instance` pragma for a derived instance. This is bad, because they are heavily used. It should probably be possible to have a top-level {{{ {-# SPECIALISE instance Eq (Int, Bool) #-} }}} even in another module (as we can now do for functions. To do this right, we'd need to make the code for derived methods `INLINEALBE`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9522> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4