February 2017 - ghc-tickets

[GHC] Trac email verification for user: coopercm
by GHC 23 Feb '17

23 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=Qtp3pZ4U> Username: coopercm Verification Token: Qtp3pZ4U -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code...
by GHC 23 Feb '17

23 Feb '17

#12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (LLVM) | 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: -------------------------------------+------------------------------------- Since in many cases, the use of the LLVM backend is the only way to avoid the NCG's poor register allocation (ticket #8971), this is a concern that using "-fllvm" is producing overly complex code through a (seeming) failed attempt to optimize. The following code uses a very simple "odds-only" implementation of the Sieve of Eratosthenes with a very tight inner culling loop limited to using a 16 Kilobyte buffer (<= the size of most modern CPU L1 data cache size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for better speed than using a variable shift left operation for setting the composite bits in the buffer array as it (should) take the same number of registers and the array look-up instruction is easier for the CPU to fuse than a variable shift left: {{{#!hs -- GHC_EfficiencyBug.hs {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2 import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base numLOOPS = 10000 :: Int twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soe :: () -> [Word32] soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfLmt then loop (n - 1) else do isCmpst <- unsafeRead cmpstsb i if isCmpst then cullp (i + 1) else -- is Prime let cull j = -- very tight inner loop where all the time is spent if j > bfLmt then cullp (i + 1) else do let sh = unsafeAt twos (j .&. 31) -- (1 `shiftL` (j .&. 31))) let w = j `shiftR` 5 ov <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (ov .|. sh) cull (j + p) in cull s in cullp 0 loop numLOOPS main = print $ length $ soe() }}} The main culling is repeated "numLOOPS" times to get a reasonable execution time for accurate timing and to make the time required to use the List comprehension to determine the number of found primes (the answer) a negligible part of the execution time. Timing results can be produced by running "./GHC_EfficiencyBug +RTS -s". The desired assembly code result for the tight inner loop is as for the Rust/LLVM compiler, in this case for x86_64 64-bit code: {{{ .p2align 4, 0x90 .LBB10_27: movq %rcx, %rdx shrq $5, %rdx movl %ecx, %esi andl $31, %esi movl (%rbp,%rsi,4), %esi orl %esi, (%r14,%rdx,4) addq %rax, %rcx .LBB10_26: cmpq %r13, %rcx jb .LBB10_27 }}} The above code is extremely efficient on a CPU that is not cache bottle necked (such as the AMD Bulldozer series are) and takes just about three clock cycles per inner composite culling loop on Intel Sky Lake; it is just as efficient for x86 code since there are only seven registers used in this inner loop. Due to this attempt at "over-optimization", the GHC/LLVM backend produces the following x86_64 64-bit code: {{{ .align 16, 0x90 .LBB34_2: # %c8T2 # =>This Inner Loop Header: Depth=1 movq %rcx, %rsi sarq $5, %rsi movl %r8d, %edi andl $124, %edi movl 16(%rax,%rdi), %edi orl %edi, 16(%r11,%rsi,4) addq %r14, %rcx addq %rdx, %r8 cmpq %r10, %rcx jle .LBB34_2 }}} As can be seen, instead of just masking the "twos" index register by 31 (0x1F), the code is using two extra separate registers to contain "(j * 4)" increment and the accumulated index, which increment is added to the "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), requiring an extra two registers and an extra instruction for the extra addition. This isn't a problem as to the number of registers for x86_64 code which has more than enough, but it adds the extra instruction execution time of one third of a CPU clock cycle (I know, only one ninth extra time). However, for 32-bit x86 code with barely enough registers previously, the use of the extra registers triggers a chain of three register reloads as can be seen in the following assembly code: {{{ .align 16, 0x90 LBB33_2: # %c8Wb # =>This Inner Loop Header: Depth=1 movl %ebx, %ebp sarl $5, %ebp movl %edi, %ecx andl $124, %ecx movl %esi, %edx movl %eax, %esi movl 36(%esp), %eax # 4-byte Reload movl 8(%eax,%ecx), %ecx movl %esi, %eax movl %edx, %esi orl %ecx, 8(%esi,%ebp,4) addl 32(%esp), %ebx # 4-byte Folded Reload addl 28(%esp), %edi # 4-byte Folded Reload cmpl %eax, %ebx jle LBB33_2 }}} '''The above code runs about 25% slower than it should on Intel Sky Lake for this 32-bit code.''' This was tested for GHC version 8.0.1 under both Windows and Linux for both 32-bit and 64-bit code with identical results for each native code width. The code was also tested for 32 and 64 bit code produced by the NCG; for this specific problem, NCG takes the simple approach and does not waste the extra register. However, due to the inefficient allocation of registers as per ticket #8971, not moving the loop completion check to the end of the loop and thus requiring an extra jump instruction, and not combining the read/modify/write into a single instruction, it is still slower (much slower for 32-bit code) than the LLVM produced code. As its problems are known, I have not documented the NCG code. Conclusion: This may seem like a nit picky type of bug as in some use cases the execution time cost is very small, but it may be an indication of problems in other use cases that cause more serious effects on execution speed. It is my feeling that for such low level somewhat imperative types of code, GHC should really produce code that is as fast as C/C++/Rust. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13318: ghc-7.10.1 panics when compiling singletons-1.1.2.1
by GHC 22 Feb '17

22 Feb '17

#13318: ghc-7.10.1 panics when compiling singletons-1.1.2.1 -------------------------------------+------------------------------------- Reporter: WrenThornton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not sure if this has been fixed in newer versions or not, but: {{{ [39 of 45] Compiling Data.Singletons.Prelude.List ( src/Data/Singletons/Prelude/List.hs, dist/build/Data/Singletons/Prelude/List.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule n_X2iZh [a_a2gBn, t_a2gBo, n_a2iB7, ipv_s2szc, ipv_s2szd, sc_s2tXD, sc_s2tXF, sc_s2tXG, sg_s2tXH] [a_X2gZv, t_X2gZx, n_X2iZh, ipv_X2sXn, ipv_X2sXp, sc_X2ulQ, sc_X2ulT, sc_X2ulV, sg_X2ulX] [TYPE a_a2gBn, TYPE t_a2gBo, TYPE Let1627878522XsSym4 t_a2gBo n_a2iB7 ipv_s2szc ipv_s2szd, sc_s2tXD, (SCons @ a_a2gBn @ (ipv_s2szc : ipv_s2szd) @ ipv_s2szc @ ipv_s2szd @~ <ipv_s2szc : ipv_s2szd>_N sc_s2tXF sc_s2tXG) `cast` (sg_s2tXH :: R:Sing[]z (ipv_s2szc : ipv_s2szd) ~R# Sing (Apply (Apply (:$) ipv_s2szc) ipv_s2szd))] [TYPE a_a2gBn, TYPE t_a2gBo, TYPE Let1627878522XsSym4 t_a2gBo ipv_s2szc ipv_X2sQZ ipv_X2sR1, sc_s2tXD, (SCons @ a_a2gBn @ (ipv_X2sQZ : ipv_X2sR1) @ ipv_X2sQZ @ ipv_X2sR1 @~ <ipv_X2sQZ : ipv_X2sR1>_N ipv_s2szf ipv_s2szg) `cast` (Sub (Sym (TFCo:R:Sing[]z[0] <a_a2gBn>_N)) (Sym (TFCo:R:Apply[][]:$$l0[0] <a_a2gBn>_N <ipv_X2sR1>_N <ipv_X2sQZ>_N) ; (Apply (Sym (TFCo:R:Apply(->)k:$l0[0] <a_a2gBn>_N <ipv_X2sQZ>_N)) <ipv_X2sR1>_N)_N) :: R:Sing[]z (ipv_X2sQZ :$$$ ipv_X2sR1) ~R# Sing (Apply (Apply (:$) ipv_X2sQZ) ipv_X2sR1))] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13319: Generate makefile dependencies suitable for ghc --make!
by GHC 22 Feb '17

22 Feb '17

#13319: Generate makefile dependencies suitable for ghc --make! -------------------------------------+------------------------------------- Reporter: 1chb | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- When using `ghc --make` to generate a binary, I'm interested to know what source files was used. I want that information to tell when to regenerate the binary. Yes, I use a `gmake` files to build my binaries even for `ghc` generated binaries. `gmake` is very convenient and useful as is `ghc --make`, but it is difficult to combine these two. For now, I can always call `ghc --make` but it takes extra build times. Especially when there are many binaries to build. I have considered the `-M` flag but it seems to be usable for separate compilation only. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7204: Use a class to control FFI marshalling
by GHC 22 Feb '17

22 Feb '17

#7204: Use a class to control FFI marshalling -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 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 RyanGlScott): Now that #2721/#8165 have been fixed, the technical obstacle of not being able to use `GeneralizedNewtypeDeriving` on classes with associated types is gone. The only question remaining is if we want to pursue this design. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7204#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12863: Associated data families don't use superclasses when deriving instances
by GHC 22 Feb '17

22 Feb '17

#12863: Associated data families don't use superclasses when deriving instances -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- {{{#!hs class Functor (TotalMap key) => Key key where data TotalMap key :: Type -> Type (¡) :: TotalMap key val -> key -> val }}} a constraint `Key key` entails a `Functor (TotalMap key)` constraint, using the notation of [https://hackage.haskell.org/package/constraints constraints] {{{#!hs prf1 :: Key key :- Functor (TotalMap key) prf1 = Sub Dict prf2 :: (Key key1, Key key2) :- (Functor (TotalMap key1), Functor (TotalMap key2)) prf2 = prf1 *** prf1 }}} Yet these proofs are not used in {{{#!hs -- tzLp.hs:28:89-95: error: … -- • No instance for (Functor (TotalMap key1)) -- arising from the first field of ‘PairMap’ -- (type ‘TotalMap key1 (TotalMap key2 val)’) -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Functor (TotalMap (key1, key2))) -- Compilation failed. instance (Key key1, Key key2) => Key (key1, key2) where data TotalMap (key1, key2) val = PairMap (TotalMap key1 (TotalMap key2 val)) deriving Functor (¡) :: TotalMap (key1, key2) val -> ((key1, key2) -> val) PairMap keys ¡ (k1, k2) = keys ¡ k1 ¡ k2 }}} I would expect it to work like {{{#!hs deriving instance (Key key1, Key key2) => Functor (TotalMap (key1, key2)) }}} Same problem occurs with only a single constraint {{{#!hs -- tzLp.hs:33:14-20: error: … -- • No instance for (Functor (TotalMap key)) -- arising from the first field of ‘Id’ (type ‘TotalMap key val’) -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Functor -- (TotalMap (Identity key))) -- Compilation failed. instance Key key => Key (Identity key) where data TotalMap (Identity key) val = Id (TotalMap key val) deriving Functor }}} which should work like {{{#!hs deriving instance Key key => Functor (TotalMap (Identity key)) -- or deriving instance Functor (TotalMap key) => Functor (TotalMap (Identity key)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12863> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4815: Instance constraints should be used when deriving on associated data types
by GHC 22 Feb '17

22 Feb '17

#4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12863 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12863 Comment: See also #12863 for another occurrence of this design question. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4815#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13244: Error Dealing with Unboxed Types and Type Families
by GHC 22 Feb '17

22 Feb '17

#13244: Error Dealing with Unboxed Types and Type Families ----------------------------------------+--------------------------------- Reporter: sgschlesinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: pprIfaceCo | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Hello, I was playing with unboxed types and this happened: [2 of 2] Compiling Data.Unbox ( Data/Unbox.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Data/Unbox.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): pprIfaceCo I will attach the relevant file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5302: Unused arguments in join points
by GHC 22 Feb '17

22 Feb '17

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Still reproducible in HEAD. * The reason the late demand-analysis doesn't catch it is because we don't do w/w. (Reason: see `Note [Final Demand Analyser run]` in `DmdAnal`.) * The absent argument is actually a case binder, passed as a result of `Note [Case binders and join points]` in `Simplify`. But in this case it turns out that not only is the case-binder argument eventually unused, but (even worse) every `juump` to that join point looks like `jump j x (I# x)`. So we box it, and then immediately discard it. Urk. Just recording breadcrumbs for now. My thought: never pass the case binder to a join point; instead re-box it. It's much the same trade-off as in other places where we worry about re-boxing. And it would be a lot simpler; in particular, we can stop having unfoldings in lambda-binders, which is pretty dodgy anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13300: panic! isInjectiveTyCon sees a TcTyCon W
by GHC 22 Feb '17

22 Feb '17

#13300: panic! isInjectiveTyCon sees a TcTyCon W -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code causes the compiler to panic {{{ #!haskell {-# LANGUAGE GADTs #-} data W where WI :: Int WD :: Double data Superblock = A { f :: W } | B { f :: W } }}} {{{ [1 of 1] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.2.0/build/hdf5/hdf5-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon W Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building package hdf5-0.1.0.0 using: /home/siddhu/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.2.0-ghc-8.0.2 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.2.0 build exe:hdf5 --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5