February 2018 - ghc-tickets

[GHC] #12126: Bad error messages for SPECIALIZE pragmas
by GHC 09 Dec '18

09 Dec '18

#12126: Bad error messages for SPECIALIZE pragmas -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Specialize, | Operating System: Unknown/Multiple ErrorMessages | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When playing with SPECIALIZE pragmas, I've encountered one large problem with the error messages, and two minor ones. 1. Given a function with a `Num` constraint, applying `SPECIALIZE` at a non-function type triggers defaulting incorrectly; the code {{{#!hs f1 :: Num a => a -> a f1 x = x + x {-# SPECIALIZE f1 :: Bool #-} }}} produces the error {{{ …/Test1.hs:5:1: error: • Couldn't match expected type ‘Integer -> Integer’ with actual type ‘Bool’ • In the SPECIALISE pragma {-# SPECIALIZE f1 :: Bool #-} }}} (This is in the attached file `Test1.hs`.) 2. Given a function, applying `SPECIALIZE` at a well-formed type without the looked-for instance produces an error with some extra text (the first line ends with "a SPECIALISE pragma for ‘f2’", even though this is repeated on the next line); the code {{{#!hs f2 :: Num a => a -> a f2 x = x + x {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} produces the error {{{ …/Test2.hs:5:1: error: • No instance for (Num Bool) a SPECIALISE pragma for ‘f2’ • In the SPECIALISE pragma {-# SPECIALIZE f2 :: Bool -> Bool #-} }}} (This is in the attached file `Test2.hs`.) 3. This is minor, but: both of these error messages talk about a `SPECIALISE` pragma when I wrote a `SPECIALIZE` pragma. Even more so, case is not preserved in the quoted pragma; if I provide a {{{#!hs {-# specialize … #-} }}} pragma, the error message ends with {{{ • In the SPECIALISE pragma {-# SPECIALIZE … #-}`. }}} even though that isn't what I wrote. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13165: Speed up the RTS hash table
by GHC 09 Dec '18

09 Dec '18

#13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.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: -------------------------------------+------------------------------------- The RTS hash table is rather slow. Every lookup involves at least one indirect call (to get a hash code). It also uses separate chaining, which is itself slow. Until recently, this didn't really matter, since the RTS hash table wasn't used for anything particularly performance critical other than `StablePtr` operations. However, it has since become the bottleneck when compacting with sharing, to the point that compacting without sharing is around 10x faster and is thus the default. Fortunately, there are easy ways to make the hash table faster. These include: - Use linear probing instead of separate chaining. - Specialize for the case of pointer keys - Don't use indirect calls for hashing - Use a fast, universal hash function for pointers. - Use SSE instructions where available to do fast searches. - Minimize the number of indirections in the use of the table. In both the case of the StablePtr table and that of compact regions, the keys of the table are not GC pointers, but the values are, so there needs to be a way to ensure that the GC handles the table correctly -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags
by GHC 08 Dec '18

08 Dec '18

#14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 the following example: {{{#!hs {-# LANGUAGE CApiFFI #-} {-# OPTIONS_GHC -optc-O3 #-} module M where foreign import capi unsafe "stdlib.h exit" c_exit :: Int -> IO () }}} However, the `-optc-O3` flag has no effect, unless `ghc` is called without any `-O` flags, or with `-O0`. Here's the resulting C compiler invocations for different `-O` flags: {{{ $ ghc -fforce-recomp -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14023_0/ghc_2.c -o /tmp/ghc14023_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O0 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14045_0/ghc_2.c -o /tmp/ghc14045_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O1 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14073_0/ghc_2.c -o /tmp/ghc14073_0/ghc_3.s -Wimplicit -S -O -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O2 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14093_0/ghc_2.c -o /tmp/ghc14093_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O3 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14119_0/ghc_2.c -o /tmp/ghc14119_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} To summarise, here's the resulting effective `-O`-level passed to `gcc`: ||= GHC invocation =||= GCC invocation =||= Effective C `-O`-level =|| || `ghc` || `gcc -O3` || `-O3` || || `ghc -O0` || `gcc -O3` || `-O3` || || `ghc -O1` || `gcc -O3 -O1` || `-O1` || || `ghc -O2` || `gcc -O3 -O2` || `-O2` || || `ghc -O3` || `gcc -O3 -O2` || `-O2` || Consequently, the only way to have C code compiled with `-O3` is to force GHC into `-O0` mode; this is obviously not ideal, as it easily kills any benefit you'd gain from passing `-O3` to the C compiler... ;-) I see a few alternatives on how to resolve this: 1. Have GHC recognise `-optc-O[0-9]` and suppress automatically injecting any `-O<n>` of its own 2. Have GHC inject its automatic `-O`-flags before user-provided `-optc` flags 3. Have GHC inject `-optc` flags as late as possible on the C compiler command-line 4. Implement a new variant of the `-optc` flag which injects its flags as late as possible on the C compiler command-line -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14251: LLVM Code Gen messes up registers
by GHC 08 Dec '18

08 Dec '18

#14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.3 (LLVM) | 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: -------------------------------------+------------------------------------- Due to the way the LLVM Code Gen generates Function Singnatures, it is possible to end up mixed up registers. A slightly adapted T8064 {{{#!hs {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import GHC.Exts {-# NOINLINE f #-} f :: (Int# -> Float# -> Double# -> Float# -> Double# -> String) -> String f g = g 3# 4.0# 5.0## 6.0# 6.9## ++ " World!" {-# NOINLINE p #-} p :: Int# -> Float# -> Double# -> Float# -> Double# -> String p i j k l m = "Hello" {-# NOINLINE q #-} q :: Int# -> Int# -> Float# -> Double# -> Float# -> Double# -> String q _ i j k l m = "Hello " ++ show (F# l) ++ " " ++ show (D# m) {-# NOINLINE r #-} r :: Int# -> Float# -> Double# -> Float# -> Double# -> String r i = let !(I# z) = length [I# 1# .. I# i] in \j k l m -> p z j k l m -- ghc won't eta-expand around the length, because it has unknown cost main = do putStrLn (f p) -- fast call putStrLn (f r) -- slow call: function but wrong arity let g = last [q 1#] putStrLn (f g) -- slow call: thunk }}} will produce the following results: {{{ ../inplace/bin/ghc-stage1 -fllvm -fforce-recomp T6084.hs -O2 -o T6084-llvm && ./T6084-llvm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-llvm ... Hello World! Hello World! Hello 4.0 5.0 World! ../inplace/bin/ghc-stage1 -fasm -fforce-recomp T6084.hs -O2 -o T6084-asm && ./T6084-asm [1 of 1] Compiling Main ( T6084.hs, T6084.o ) Linking T6084-asm ... Hello World! Hello World! Hello 6.0 6.9 World! }}} The underlying reason is that (at least for X86_64) the Float and Double registers alternate. The llvm code gen creates function signatures based on the live registers (instead of all). For `q` only the last Float and Double register are `live`. However when calling `q` we pass `f1: Float -> d1: Double -> f2: Float -> d2: Double`. `f2` and `d2` are silently ignored, and in the function body, we now have `f2 <- f1` and `d2 <- d1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

[GHC] #13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3
by GHC 07 Dec '18

07 Dec '18

#13786: GHC panic on Mac OS X with "cabal repl" / "stack repl" on GHC 8.0.2 and 7.8.3 -------------------------------------+------------------------------------- Reporter: ppelleti | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing "stack repl" with GHC 8.0.2: {{{ whiteandnerdy:hs-mercury-api ppelleti$ stack repl The following GHC options are incompatible with GHCi and have not been passed to it: -threaded * * * * * * * * The main module to load is ambiguous. Candidates are: 1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr- firmware.hs 2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs 3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs 4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs 5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs 6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs You can specify which one to pick by: * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr- firmware * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe :tmr-firmware * Choosing from the candidate above [1..6] * * * * * * * * Specify main module to use (press enter to load none): 4 Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs Configuring GHCi with the following packages: mercury-api GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This bug appears to have been around a while, because it also happens with GHC 7.8.3: {{{ whiteandnerdy:hs-mercury-api ppelleti$ cabal repl Preprocessing library mercury-api-0.1.0.0... GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package bytestring-0.10.4.0 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package binary-0.7.1.0 ... linking ... done. Loading package text-1.2.2.1 ... linking ... done. Loading package hashable-1.2.6.0 ... linking ... done. Loading package unordered-containers-0.2.8.0 ... linking ... done. Loading package clock-0.7.2 ... linking ... done. Loading package old-locale-1.0.0.6 ... linking ... done. Loading package time-1.4.2 ... linking ... done. Loading package unix-2.7.0.1 ... linking ... done. Loading package ansi-terminal-0.6.2.3 ... linking ... done. Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done Loading object (static) dist/build/cbits/api/tmr_param.o ... done Loading object (static) dist/build/cbits/api/hex_bytes.o ... done Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Expected in: flat namespace in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'm using Mac OS X 10.9.5: {{{ whiteandnerdy:hs-mercury-api ppelleti$ uname -a Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13786> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13104: runRW# ruins join points
by GHC 06 Dec '18

06 Dec '18

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Found this while poking around in the example for #12781. Suppose we have code like this: {{{ let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n = ... loop (n+1) {- tail call -} ... in runRW# @ 'PtrRepLifted @ Int (loop 0) }}} We would love for `loop` to be a join point, but it can't be because it's invoked in the argument to `runRW#`. In this situation, we're often rescued by Float In, which we might hope to give us this: {{{ runRW# @ 'PtrRepLifted @ Int ( let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 ) }}} Two problems: 1. Float In won't do this to begin with because `loop 0` is a partial application. 2. It's still not eligible to be a join point, again because `loop 0` is a partial application. What we would //like// to see is this: {{{ runRW# @ 'PtrRepLifted @ Int ( \s0 -> let loop :: Int -> State# RealWorld -> (State# RealWorld, Int) loop n s = ... loop (n+1) s' {- tail call -} ... in loop 0 s0 ) }}} Now we're golden. But someone has to have thought to eta-expand the argument to `runRW#` first. (Float In should then float `loop` into the lambda because, due to the state hack, the lambda is considered one-shot.) Perhaps the simplifier should //always// eta-expand the argument to `runRW#`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14847: Inferring dependent kinds for non-recursive types
by GHC 06 Dec '18

06 Dec '18

#14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType | 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 this {{{ data Proxy k (a :: k) = MkProxy data Proxy2 k a = MkP (Proxy k a) }}} which is discussed in [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations a corner of the user manual]. Surprisingly, we reject `Proxy2` -- but there is nothing difficult about inferring its kind. There would be if it was recursive -- but it isn't. Simple solution: for non-recursive type declarations (we do SCC analysis so we know which these are) do not call `getInitialKinds`; instead, just infer the kind of the definition! Simple. Warning: is this recursive? {{{ data Proxy2 k a where MkP :: Proxy k a -> Proxy2 k a }}} Presumably no more than the other definition. But currently we need `Proxy2` in the environment during kind inference, because we kind-check the result type. That seems jolly odd and inconsistent. Needs more thought. Similar questions for {{{ data T a where T :: Int -> T Bool type family F a where F Int = True F _ = False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12088: Promote data family instance constructors
by GHC 06 Dec '18

06 Dec '18

#12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11348 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `TcEnv.hs` there is a note AFamDataCon: not promoting data family constructors. It states that we can't use a promoted data family instance constructor because we would have to interleave the checking of instances and data types. But with the fix of #11348, we now do exactly this. In the example from the note {{{#!hs data family T a data instance T Int = MkT data Proxy (a :: k) data S = MkS (Proxy 'MkT) }}} -ddump-rn-trace shows these groups {{{ rnTycl dependency analysis made groups [[data family T a_apG] [] [data instance T Int = MkT], [data Proxy (a_apF :: k_apE)] [] [], [data S = MkS (Proxy MkT)] [] []] }}} That's to say, the instance `T Int` will in fact be checked before `S`. So let's remove this restriction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 53

[GHC] #14727: Unboxed sum performance surprisingly poor
by GHC 06 Dec '18

06 Dec '18

#14727: Unboxed sum performance surprisingly poor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: UnboxedSums | 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 tried performing worker-wrapper manually on `Data.IntMap.lookup`: {{{#!hs lookup# :: Int -> IntMap a -> (# (# #) | a #) lookup# = -- The obvious modification of the current implementation lookup :: Int -> IntMap a -> Maybe a lookup k m = case lookup# k m of (# | a #) -> Just a _ -> Nothing }}} Unfortunately, the `lookup` benchmark ''slowed down''. I verified that the benchmark indeed performs an immediate case analysis on the result (with `fromMaybe`), so it ''should'' go faster. And yet it goes slower. Caveat: I have not yet gotten things set up to be able to check with 8.4, so if there have been improvements in `UnboxedSum` performance since `8.2.2`, this may all be silly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14727> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum
by GHC 06 Dec '18

06 Dec '18

#14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's the code in question: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE UnboxedTuples #-} {-# OPTIONS_GHC -O2 #-} module Byte.Array.Window ( findByte , boxMaybeInt ) where import Data.Primitive (ByteArray) import Data.Word (Word8) import GHC.Types (RuntimeRep,TYPE) import GHC.Int (Int(I#)) import GHC.Exts (Int#) import qualified Data.Primitive as PM type Maybe# (a :: TYPE (r :: RuntimeRep)) = (# (# #) | a #) boxMaybeInt :: Maybe# Int# -> Maybe Int boxMaybeInt = \case (# | a #) -> Just (I# a) (# (# #) | #) -> Nothing unboxInt :: Int -> Int# unboxInt (I# i) = i -- | Finds the first occurrence of the given byte. -- TODO: optimize this to search through a whole -- Word64 at a time if the bytearray is pinned. findByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int findByte !off !len !w !arr = boxMaybeInt (go off) where go :: Int -> Maybe# Int# go !ix = if ix < len then if PM.indexByteArray arr ix == w then (# | unboxInt ix #) else go (ix + 1) else (# (# #) | #) }}} When compiled with GHC 8.5 with `-ddump-simpl -dsuppress-all`, here is the relevant part of the resulting Core: {{{ -- RHS size: {terms: 33, types: 13, coercions: 0, joins: 1/1} $wfindByte $wfindByte = \ ww_s38C ww1_s38G ww2_s38K ww3_s38O -> joinrec { $wgo_s38v $wgo_s38v ww4_s38t = case <# ww4_s38t ww1_s38G of { __DEFAULT -> Nothing; 1# -> case indexWord8Array# ww3_s38O ww4_s38t of wild_a36w { __DEFAULT -> case eqWord# wild_a36w ww2_s38K of { __DEFAULT -> jump $wgo_s38v (+# ww4_s38t 1#); 1# -> Just (I# ww4_s38t) } } }; } in jump $wgo_s38v ww_s38C -- RHS size: {terms: 21, types: 12, coercions: 0, joins: 0/0} findByte findByte = \ w_s38w w1_s38x w2_s38y w3_s38z -> case w_s38w of { I# ww1_s38C -> case w1_s38x of { I# ww3_s38G -> case w2_s38y of { W8# ww5_s38K -> case w3_s38z of { ByteArray ww7_s38O -> $wfindByte ww1_s38C ww3_s38G ww5_s38K ww7_s38O } } } } }}} I expected that the tail recursive `go` helpful function from my original code would still be a function that returns an unboxed sum when optimized and turned into Core. However, it isn't. The call to `boxMaybeInt` gets pushed into `go`. This means that when `findByte` is called and the result cased on, an allocation is going to happen. I think it would be preferable for `boxMaybeInt` to not get pushed into the worker, since `boxMaybeInt (go off)` could be inlined and the allocation of `Maybe` could be prevented (assuming that it was cased on right afterward). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14865> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4