July 2017 - ghc-tickets

[GHC] #8472: Primitive string literals prevent optimization
by GHC 15 Aug '17

15 Aug '17

#8472: Primitive string literals prevent optimization ------------------------------+-------------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Using an Addr# literal seems to result in less aggressive optimization. If I compile the attached program like this: {{{ ghc -O2 -fforce-recomp -ddump-simpl addr.hs }}} the code is optimized nicely. Everything are inlined into {{{t}}}, intermediate pairs are eliminated, etc. However, when I replace the Int# literals in the code with Addr# literals by defining the {{{ADDR}}} macro: {{{ ghc -O2 -fforce-recomp -ddump-simpl -DADDR addr.hs }}} GHC now creates 2 extra top-level bindings, each of which allocates a pair. I don't see why the presence of Addr# literals should prevent inlining, so I'm reporting a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[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] #13367: CSE not working for top-level literal strings
by GHC 15 Aug '17

15 Aug '17

#13367: CSE not working for top-level literal strings -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MagicHash #-} module S( z ) where import GHC.Exts data T = MkT Addr# x = MkT "foo"# y = MkT "foo"# z = (x,y) }}} You'd expect those literal strings to get CSE'd but currently they are not. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13226: Compiler allocation regressions from top-level string literal patch
by GHC 15 Aug '17

15 Aug '17

#13226: Compiler allocation regressions from top-level string literal patch -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- d49b2bb21691892ca6ac8f2403e31f2a5e53feb3 leads to compiler allocation regressions in T12425 and T13035 when those tests are compiled with `-O2`. I took a look at T13035 tonight. `-v` reveals more terms and types. Interestingly, it appears that virtually all the string literals arise from the derived `Typeable` instance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13260: panic on unboxed string literal in pattern
by GHC 15 Aug '17

15 Aug '17

#13260: panic on unboxed string literal in pattern -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I don't think this program is meaningful, but it shouldn't cause a panic. {{{#!hs {-# LANGUAGE MagicHash #-} g y = case y of "a"# -> True _ -> False }}} {{{ [1 of 1] Compiling CaseOnString ( x/CaseOnString.hs, x/CaseOnString.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): litValue "a"# }}} The panic is also in at least 7.8, 7.10, and HEAD. `"a"#` has type `Addr#`, and I suppose that if we allow `case` on `Addr#` then it ought to use pointer equality. But the literal `"a"#` has no particular address, so matching against it in a `case` doesn't make sense. So I think we should just disallow unboxed string literals as patterns. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13260> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13317: exprIsConApp_maybe should deal better with strings
by GHC 15 Aug '17

15 Aug '17

#13317: exprIsConApp_maybe should deal better with strings -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider {{{ x :: Addr# x = "foo"# y = case unpackCString# x of [] -> ... (x:xs) -> ... }}} `exprIsConApp_maybe` has a special case for literal strings; see `Note [exprIsConApp_maybe on literal strings]` in `CoreSubst`. But it only works if `unpackCString#` is applied to a literal, not to a variable bound to a literal (like `x`). The fix is easy. Instead of this code {{{ , [Lit (MachStr str)] <- args = dealWithStringLiteral fun str co }}} we want to use `exprIsLiteral_maybe`, thus {{{ , Just (MachStr str) <- exprIsLiteral_maybe ... arg = dealWithStringLiteral fun str co }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13317> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13344: Core string literal patch regresses compiler performance considerably
by GHC 15 Aug '17

15 Aug '17

#13344: Core string literal patch regresses compiler performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- The Core string literals patch regresses compiler performance by nearly 5%. https://perf.haskell.org/ghc/#revision/d49b2bb21691892ca6ac8f2403e31f2a5e53… We should really understand why this is; this is a huge regression for something that really shouldn't be costly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #13390: Strict literal float-out during desugaring regresses T1969 at -O0
by GHC 15 Aug '17

15 Aug '17

#13390: Strict literal float-out during desugaring regresses T1969 at -O0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- Phab:D1259, which teaches the compiler to aggressively float-out string literals during desugaring, regresses compiler allocations on `T1969` by 15% or so at -O0`. = The problem = In the case of `T1969` (compiled with `-O0`) the difference is quite stark: with floating the non-optimizing simplifier pass produces `{terms: 16,893, types: 7,552, coercions: 0, joins: 0/0}`, without it produces `{terms: 12,693, types: 4,552, coercions: 0, joins: 0/0}`. The (minimized) test looks like, {{{#!hs module T1969 where class C a where c :: a -> String d :: a -> String d x = c x e :: a -> String e x = c x data A1 = A1 instance C A1 where c A1 = "A1" }}} == Post-desugar == The reason for the regression is in part due to the fact that we float out the `unpackCString# "An"` expression. That is, after desugaring without floating we get (looking at just the `A1` bindings), {{{#!hs T1969.$dme :: forall a. C a => a -> String T1969.$dme = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM3 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM3 -- same as $dme T1969.$dmd :: forall a. C a => a -> String T1969.$dmd = \ (@ a_aM1) ($dC_a1h9 :: C a_aM1) (x_aM2 :: a_aM1) -> c @ a_aM1 $dC_a1h9 x_aM2 $cc_a1i7 :: A1 -> String $cc_a1i7= \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } Rec { T1969.$fCA3 :: C A3 T1969.$fCA3 = T1969.C:C @ A3 $cc_a1hl $cd_a1hp $ce_a1hy $ce_a1hy :: A3 -> String $ce_a1hy = T1969.$dme @ A3 T1969.$fCA3 $cd_a1hp :: A3 -> String $cd_a1hp = T1969.$dmd @ A3 T1969.$fCA3 end Rec } }}} Whereas with floating we get, {{{#!hs -- same as above T1969.$dme :: forall a. C a => a -> String T1969.$dmd :: forall a. C a => a -> String ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } Rec { T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik $ce_a1ik :: A1 -> String $ce_a1ik = T1969.$dme @ A1 T1969.$fCA1 $cd_a1ib :: A1 -> String $cd_a1ib = T1969.$dmd @ A1 T1969.$fCA1 end Rec } }}} So far things aren't so bad: the only interesting difference is the floated `[Char]`, which we would expect. However, let's then see what happens during simplification. == Post-simplification == Without floating we see, {{{#!hs T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cc_a1i7 $cc_a1i7 $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1jJ :: A1) -> case ds_d1jJ of { A1 -> GHC.CString.unpackCString# "A1"# } }}} Whereas with floating we have, {{{#!hs ds_d1k4 :: [Char] ds_d1k4 = GHC.CString.unpackCString# "A1"# $cc_a1i7 :: A1 -> String $cc_a1i7 = \ (ds_d1k3 :: A1) -> case ds_d1k3 of { A1 -> ds_d1k4 } $cd_a1ib :: A1 -> String $cd_a1ib = \ (x_aM2 :: A1) -> case x_aM2 of { A1 -> ds_d1k4 } $ce_a1ik :: A1 -> String $ce_a1ik = \ (x_aM3 :: A1) -> case x_aM3 of { A1 -> ds_d1k4 } T1969.$fCA1 :: C A1 T1969.$fCA1 = T1969.C:C @ A1 $cc_a1i7 $cd_a1ib $ce_a1ik }}} This is quite interesting: without floating we are somehow able to collapse each of the `A1 -> String` bindings into a single binding (despite CSE being disabled due to `-O0`!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13390> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13