June 2014 - ghc-tickets

[GHC] #8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64)
by GHC 20 Nov '14

20 Nov '14

#8311: suboptimal code generated for even :: Int -> Bool by NCG (x86, x86_64) ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This appears to be the x86 assembly for a specialization for `even :: Int -> Bool` that's produced by a SPECIALISE pragma for `(^) :: Int -> Int -> Int` in GHC.Real. The relevant bit is offsets `0x2c` through `0x3b`. {{{ 0000000c <base_GHCziReal_evenzuzdseven1_info>: c: 8b 45 00 mov 0x0(%ebp),%eax f: c7 45 00 2c 00 00 00 movl $0x2c,0x0(%ebp) 12: R_386_32 .text 16: 89 c6 mov %eax,%esi 18: f7 c6 03 00 00 00 test $0x3,%esi 1e: 75 0c jne 2c <c8gO_info> 20: ff 26 jmp *(%esi) 22: 66 90 xchg %ax,%ax 24: 00 00 add %al,(%eax) 26: 00 00 add %al,(%eax) 28: 20 00 and %al,(%eax) ... 0000002c <c8gO_info>: 2c: b8 02 00 00 00 mov $0x2,%eax 31: 89 c1 mov %eax,%ecx 33: 8b 46 03 mov 0x3(%esi),%eax 36: 99 cltd 37: f7 f9 idiv %ecx 39: 85 d2 test %edx,%edx 3b: 75 0b jne 48 <c8gO_info+0x1c> 3d: be 02 00 00 00 mov $0x2,%esi 3e: R_386_32 ghczmprim_GHCziTypes_True_closure 42: 83 c5 04 add $0x4,%ebp 45: ff 65 00 jmp *0x0(%ebp) 48: be 01 00 00 00 mov $0x1,%esi 49: R_386_32 ghczmprim_GHCziTypes_False_closure 4d: 83 c5 04 add $0x4,%ebp 50: ff 65 00 jmp *0x0(%ebp) }}} It would be much better to do a simple `testb $0x1,0x3(%esi)` in place of the first six instructions of `c8gO_info`. The NCG generates similar code on x86_64. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8311> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8313: Poor performance of higher-order functions with unboxing
by GHC 20 Nov '14

20 Nov '14

#8313: Poor performance of higher-order functions with unboxing -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: task | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 7.6.3 Keywords: slow unboxed | Operating System: Unknown/Multiple higher order | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I was testing out some code to see how GHC handled some unboxed higher- order functions, and was suprised by the results I found. Here is some sample code: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} import GHC.Exts import System.Environment rel# :: Int# -> Int# -> Int# -> Bool rel# i# j# k# = (i# +# j# +# k#) ># 100000000# rel :: Int -> Int -> Int -> Bool rel (I# i#) (I# j#) (I# k#) = rel# i# j# k# manual :: (Int# -> Int# -> Int# -> Bool) -> (Int, Int, Int) manual r# = go 0# 0# 0# where go i# j# k# | r# i# j# k# = (I# i#, I# j#, I# k#) | otherwise = go j# k# (i# +# 1#) {-# NOINLINE manual #-} auto :: (Int -> Int -> Int -> Bool) -> (Int, Int, Int) auto r = go 0 0 0 where go !i !j !k | r i j k = (i, j, k) | otherwise = go j k (i+1) {-# NOINLINE auto #-} main = getArgs >>= \case "manual" : _ -> print $ manual rel# -- This case is significantly slower. "auto" : _ -> print $ auto rel -- Why? }}} A loop that has to box its loop parameters to call a predicate turns out to be significantly faster than one that uses a predicate that takes unboxed values directly. The answer turns out to be (I believe) in ghc/utils/genapply/GenApply.hs. applyTypes has an entry [P,P,P], but only [N]. This means that the manual loop has to use a slower calling convention than the boxed loop. I'm not sure whether this should be 'fixed,' as my encounter with it was experimental in nature, and I don't have a real use case. The comment on applyTypes says its cases cover 99% of uses, and mine is not a real use. This ticket may serve as documentation at least, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8318: GHC does not infer type of `tagToEnum#` expression
by GHC 20 Nov '14

20 Nov '14

#8318: GHC does not infer type of `tagToEnum#` expression ----------------------------+---------------------------------------------- Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects valid program Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Compiling this program: {{{ {-# LANGUAGE MagicHash #-} module TTE where import GHC.Prim f = case tagToEnum# 1# of True -> "True" False -> "False" }}} gives a compilation error: {{{ [1 of 1] Compiling TTE ( tte.hs, tte.o ) tte.hs:6:10: tagToEnum# must appear applied to one argument In the expression: tagToEnum# 1# In the expression: case tagToEnum# 1# of { True -> "True" False -> "False" } In an equation for ‛f’: f = case tagToEnum# 1# of { True -> "True" False -> "False" } }}} To make it work one needs to supply type annotation for `tagToEnum#`: `case tagToEnum# 1# :: Bool of`. I would expect however that type will be inferred from type of patterns in the branches. Although I can imagine that things might get complicated for an ill-typed program: {{{ f = case tagToEnum# 1# of True -> "True" 3 -> "What now?" }}} If it is not possible to infer type of scrutinee based on patterns then I would expect to get more informative error message. Current one - `tagToEnum# must appear applied to one argument` - is very misleading. When I saw it for the first time it took me about 15 minutes to actually figure out what GHC expects me to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955)
by GHC 20 Nov '14

20 Nov '14

#8319: Simplifier ticks exhausted (need -fsimpl-tick-factor=955) -----------------------------------+--------------------------------------- Reporter: ruudkoot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Attached file needs a rather high simpl-tick-factor (955) in order to compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8324: ghci failed on startup
by GHC 20 Nov '14

20 Nov '14

#8324: ghci failed on startup ------------------------------------+------------------------------- Reporter: dabraham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------- fred:~ danielabraham$ ghci GHCi, version 7.6.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. ghc: internal error: evacuate: strange closure type 0 (GHC version 7.6.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap fred:~ danielabraham$ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8336: Sinking pass does not
by GHC 20 Nov '14

20 Nov '14

#8336: Sinking pass does not ------------------------------+-------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Compiling this program: {{{ {-# LANGUAGE BangPatterns, MagicHash, CPP #-} {-# OPTIONS_GHC -O2 -funbox-strict-fields #-} module HashStr where import Foreign.C import GHC.Exts import Data.Word #define hASH_TBL_SIZE 4091 hashStr :: Ptr Word8 -> Int -> Int -- use the Addr to produce a hash value between 0 & m (inclusive) hashStr (Ptr a#) (I# len#) = loop 0# 0# where loop h n | n GHC.Exts.==# len# = I# h | otherwise = loop h2 (n GHC.Exts.+# 1#) where !c = ord# (indexCharOffAddr# a# n) !h2 = (c GHC.Exts.+# (h GHC.Exts.*# 128#)) `remInt#` hASH_TBL_SIZE# }}} produces following Cmm code for `hashStr` function: {{{ {offset cut: goto cux; cux: _stC::I64 = R3; _stB::I64 = R2; _stF::I64 = 0; _stE::I64 = 0; goto stD; stD: if (_stF::I64 == _stC::I64) goto cuH; else goto cuI; cuH: R1 = _stE::I64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cuI: _stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; _stE::I64 = _stM::I64; goto stD; } }}} The problem here is that three last assignments: {{{ _stM::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; _stE::I64 = _stM::I64; }}} could be optimized as: {{{ _stE::I64 = %MO_S_Rem_W64(%MO_UU_Conv_W8_W64(I8[_stB::I64 + _stF::I64]) + (_stE::I64 << 7), 4091); _stF::I64 = _stF::I64 + 1; }}} We should improve sinking pass so that it can optimize such cases. See Note [dependent assignments] in CmmSink. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8372: enable -dcmm-lint by default for .cmm input files
by GHC 19 Nov '14

19 Nov '14

#8372: enable -dcmm-lint by default for .cmm input files ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I'm finding it's quite easy to write `.cmm` files with subtle errors that cause ghc to emit code that wasn't what I wanted! For example, I wrote a comparison between two arguments of different integer sizes and the code generator picked the wrong size. After tracking down the bug, I tried `-dcmm-lint` and it caught my error right away. It makes sense not to have `-dcmm-lint` enabled by default for Cmm produced from Stg, but I've seen here on the GHC wiki that `-dcmm-lint` is advised for hand-written `.cmm` files. But `integer-gmp`, and probably many other packages, don't build `.cmm` files with `-dcmm-lint`. Is there a reason we can't/shouldn't just make it the default? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8388: forall on non-* types
by GHC 19 Nov '14

19 Nov '14

#8388: forall on non-* types ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE RankNTypes, ImpredicativeTypes #-} x = Nothing :: (forall a. Maybe) Int }}} gives {{{ Couldn't match type `Maybe' with `forall a. Maybe' Expected type: forall a. Maybe Int Actual type: Maybe Int }}} which does not seem correct. There are two options: Option A: We allow this. Option B: We reject this as ill-kinded and allow `forall a. T` only when `T` has kind `*`. I prefer this option; in theory this can break existing code, but I am not aware of any code that uses forall on non-* type (please correct me if I'm wrong), and e.g. this means `forall a. a` inhabits every kind, for example `Bool`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8388> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld
by GHC 19 Nov '14

19 Nov '14

#8394: T7478 fails on i386 Linux with "unresolvable R_386_32 relocation" from ld ----------------------------+--------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8294 | ----------------------------+--------------------------------- Much like #8294. Here is the error messages from the debug output: {{{ /usr/bin/ld: dynamic variable `base_GHCziBase_zdfMonadIO_closure' is zero size /usr/bin/ld: dynamic variable `ghczmprim_GHCziTuple_Z0T_closure' is zero size /usr/bin/ld: dynamic variable `base_GHCziTopHandler_runMainIO_closure' is zero size /usr/bin/ld: C.o(.text+0x59): unresolvable R_386_32 relocation against symbol `base_GHCziBase_zdfMonadIO_closure' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8394> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8398: reify module list in TH
by GHC 19 Nov '14

19 Nov '14

#8398: reify module list in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8337 | Test Case: | Blocking: 7867 -------------------------------------------+------------------------------- This patch is for the use-case detailed in #7867. The added Q monad method provides the ability to get a list of module names in a format that is compatible with the module annotation reification in #8337. The patch contains a helper method that depends on #8337, so that should be applied first. If this is problematic, it's easy to separate this patch into one that doesn't depend on #8337 and an other that does. Then we can add the latter later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5