December 2015 - ghc-tickets

[GHC] #9279: Optimisation bug
by GHC 18 Jan '19

18 Jan '19

#9279: Optimisation bug ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I have a strange problem with a local function binding that is not being inlined. I've attached the repro code, build it like this: {{{ $ ghc -O2 Haxl/Core/Monad.hs }}} There are several modules, but the one with the problem is `Haxl/Core/Monad.hs`. In particular `Haxl.Core.Monad.$fApplicativeGenHaxl2`, which contains this fragment: {{{ let { $wa4_s6YQ $wa4_s6YQ = \ w_s6YF _ ww1_s6YM _ _ w1_s6YI -> case GHC.Prim.readMutVar# ipv7_X5Ne w1_s6YI of _ { (# ipv10_X5QO, ipv11_X5QQ #) -> case ipv11_X5QQ of _ { Haxl.Core.Monad.IVarFull a2_a3kK -> case lvl6_r7qi of wild3_00 { }; Haxl.Core.Monad.IVarEmpty dt2_d4Vs -> case GHC.Prim.writeMutVar# ipv7_X5Ne (Haxl.Core.Monad.IVarFull w_s6YF) ipv10_X5QO of s2#_a5OR { __DEFAULT -> case GHC.Prim.readMutVar# dt2_d4Vs s2#_a5OR of _ { (# ipv12_X5R0, ipv13_X5R2 #) -> case GHC.Prim.readMutVar# ww1_s6YM ipv12_X5R0 of _ { (# ipv14_X5SS, ipv15_X5SU #) -> letrec { go_a5ti go_a5ti = \ ds10_a5tj -> case ds10_a5tj of _ { [] -> ipv15_X5SU; : y_a5to ys_a5tp -> GHC.Types.: (y_a5to w_s6YF) (go_a5ti ys_a5tp) }; } in case go_a5ti ipv13_X5R2 of x'_a5P6 { __DEFAULT -> case GHC.Prim.writeMutVar# ww1_s6YM x'_a5P6 ipv14_X5SS of s2#1_a5P7 { __DEFAULT -> (# s2#1_a5P7, Haxl.Core.Monad.cacheRequest6 #) } } } } } } } } in let { a2_s6lH a2_s6lH = \ w_s6YF _ w2_s6YH w3_s6YI -> case w2_s6YH of _ { Haxl.Core.Monad.SchedState ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO -> $wa4_s6YQ w_s6YF ww1_s6YL ww2_s6YM ww3_s6YN ww4_s6YO w3_s6YI } } in }}} I want `$wa4` to be inlined at its single occurrence in `a2`. I believe the reason it is not being inlined is that `a2` is a wrapper, but the situation seems silly because the wrapper isn't going away either, so we have a redundant closure being built (this is in my inner loop). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #11126: Entered absent arg in a Repa program
by GHC 18 Jan '19

18 Jan '19

#11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs module Main where import Data.Array.Repa data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show through :: Maybe Double -> Stuff -> Stuff m `through` (a `With` _) = let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a)) c = maybe b (const (negate `smap` a)) m in computeUnboxedS c `With` sumAllS b main :: IO () main = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1) }}} It should produce the following result once run. {{{#!hs AUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0 }}} However, when built using `repa-3.4.0.1` and compiled with the options `-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`, it crashes as follows. {{{#!hs Main: Oops! Entered absent arg arr2 Array D DIM1 Double }}} Adding `-fno-strictness` to the compiler options or removing strictness annotations from the code makes the problem disappear, so this looks like a strictness analyzer problem. The libraries used were * `QuickCheck-2.8.1`, * `array-0.5.1.0`, * `base-4.8.1.0`, * `bytestring-0.10.6.0`, * `containers-0.5.6.2`, * `deepseq-1.4.1.1`, * `ghc-prim-0.4.0.0`, * `integer-gmp-1.0.0.0`, * `pretty-1.1.2.0`, * `primitive-0.6`, * `random-1.1`, * `repa-3.4.0.1`, * `template-haskell-2.10.0.0`, * `tf-random-0.5`, * `time-1.5.0.1`, * `transformers-0.4.2.0` and * `vector-0.10.12.3`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10918: Float once-used let binding into a recursive function
by GHC 18 Jan '19

18 Jan '19

#10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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): | -------------------------------------+------------------------------------- Consider this code {{{#!hs let x = f x0 in let go 10 = x go i = go (i+1) in go (0::Int) }}} Currently, this is pretty much the core that comes out at the end. But what we want to see instead is {{{#!hs let go 10 = let x = f x 0 in x go i = go (i+1) in go (0::Int) }}} In general, we do not want to float a binding into a recursive function, because we would risk doing the allocation and/or evaluation of it multiple times. But in this case, we can see that it is going to be used at most once, so it is safe to do so. Even more: In the slightly less contrived examples that I was looking at, the call to `x` was happening in the a less likely code path, so this way we’d avoid doing the allocation in most cases, a clear win. It might be enough to simply make `CallArity` (or rather the cardinality analysis done by call arity) tell the rest of the compiler that it found that `x` is called at most once, and hopefully the simplifier knows what to make of that information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult
by GHC 18 Jan '19

18 Jan '19

#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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: -------------------------------------+------------------------------------- After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up. I then opened up haskell-src-exts and found the function I wanted in a minute or two. {{{#!hs import qualified Language.Haskell.Exts.Parser as P parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}} This is where I got stuck: {{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}} This is the code I was working with before I gave up on GHC: {{{#!hs module ParsePls where import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST import System.Environment main :: IO () main = do [expr] <- getArgs parsePls expr parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ‘HsExpr’ let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}} Is there a reason it has to be this difficult? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading
by GHC 11 Jan '19

11 Jan '19

#10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- J Garrett Morris describes the following surprising behaviour for typed Template Haskell {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} module PrintfLib where import Language.Haskell.TH class Printf t where printf :: String -> Q (TExp String) -> Q (TExp t) instance Printf [Char] where tf s t | '%' `notElem` s = [|| $$t ++ s ||] | otherwise = fail ("Unexpected format %" ++ [c]) where (_, _:c:_) = break ('%' ==) s instance Printf t => Printf (Char -> t) where printf s t | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ " for character") | otherwise = [|| \c -> $$(printf s'' [|| $$t ++ s' ++ [c] ||]) ||] where (s', '%':c:s'') = break ('%' ==) s ------------------------- {-# LANGUAGE TemplateHaskell #-} module Printf where import PrintfLib f :: Char -> String f = $$(printf "foo %c" [||""||]) h :: Char -> String h y = $$(printf "foo %c" [||""||]) y }}} Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- expanded version of `f`: {{{ Printf.hs:9:10: No instance for (Printf t0) arising from a use of ‘printf’ The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance Printf t => Printf (Char -> t) -- Defined in ‘PrintfLib’ instance Printf [Char] -- Defined in ‘PrintfLib’ In the expression: printf "foo %c" [|| "" ||] }}} What is going on? Here's the deal * To run the splice, GHC must solve any constraints that arise form the expression `(printf "foo %c" ...)`. * Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed. * In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve. * But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint. You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example: {{{ hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] }}} Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traveral order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce. I'm not sure what to do about this. * It seldom matters, because resolving the overloading on the splice seldom depends on the result type. * When it does matter, you can fix it by giving a type signature to the splice itself. But it seems unsatisfactory. Ideas welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic
by GHC 11 Jan '19

11 Jan '19

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.10.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When I say: {{{#!hs m :: a -> a m x = $$([||_||]) }}} I get: {{{ T10946.hs:47:13:ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: a_apJ[sk] }}} This happens both with GHC 7.10.1 and latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #10945: Typed Template Haskell splices broken in HEAD (7.11)
by GHC 11 Jan '19

11 Jan '19

#10945: Typed Template Haskell splices broken in HEAD (7.11) -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.11 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- In the latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e) when I say: {{{#!hs $$(return [ SigD (mkName "m") (ForallT [PlainTV (mkName "a")] [] (AppT (AppT ArrowT (VarT (mkName "a"))) (VarT (mkName "a")))) , FunD (mkName "m") [Clause [VarP (mkName "x")] (NormalB (VarE (mkName "x"))) []] ]) }}} I get: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151007 for x86_64-unknown-linux): runRnSplice $$(return [SigD (mkName "m") (ForallT [PlainTV (mkName "a")] [] (AppT (AppT ArrowT (VarT (mkName "a"))) (VarT (mkName "a")))), FunD (mkName "m") [Clause [VarP (mkName "x")] (NormalB (VarE (mkName "x"))) []]]) }}} This code compiles correctly in GHC 7.10.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10945> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10949: Document typed Template Haskell
by GHC 11 Jan '19

11 Jan '19

#10949: Document typed Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- As far as I can tell, typed Template Haskell is completely missing from the manual. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8326: Place heap checks common in case alternatives before the case
by GHC 07 Jan '19

07 Jan '19

#8326: Place heap checks common in case alternatives before the case ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | 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: 8317 Related Tickets: #1498 | ------------------------------------+------------------------------------- We would like to have functions that check whether an `Int#` is a valid tag to represent `Bool` (see Note [Optimizing isTrue#] in ghc-prim): {{{ isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False isFalse# :: Int# -> Bool isFalse# 0# = True isFalse# _ = False }}} We could use them with comparison primops like this: {{{ f :: Int# -> Int f x | isTrue# (x ># 0#) = I# x | otherwise = -(I# x) }}} `isTrue#` is optimized away at the Core level: {{{ A.f = \ (x_aqM :: GHC.Prim.Int#) -> case GHC.Prim.># x_aqM 0 of _ { __DEFAULT -> GHC.Types.I# (GHC.Prim.negateInt# x_aqM); 1 -> GHC.Types.I# x_aqM } }}} but the code genrator produces very bad Cmm code, because it pushes heap checks into case alternatives: {{{ {offset cFd: // stack check if ((Sp + -16) < SpLim) goto cFr; else goto cFs; cFr: // not enough place on the stack, call GC R2 = R2; R1 = A.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cFs: // scrutinize (x ># 0#) _sEU::I64 = R2; _sEV::I64 = %MO_S_Gt_W64(R2, 0); if (_sEV::I64 != 1) goto cFg; else goto cFo; cFg: // False branch Hp = Hp + 16; if (Hp > HpLim) goto cFy; else goto cFx; cFy: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFf; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFf, args: 8, res: 8, upd: 8; cFf: // re-do the False branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFg; cFx: // RHS of False branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = -_sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cFo: // True branch Hp = Hp + 16; if (Hp > HpLim) goto cFv; else goto cFu; cFv: // not enough heap, call GC HpAlloc = 16; I64[Sp - 16] = cFn; R1 = _sEV::I64; I64[Sp - 8] = _sEU::I64; Sp = Sp - 16; call stg_gc_unbx_r1(R1) returns to cFn, args: 8, res: 8, upd: 8; cFn: // re-do the True branch _sEU::I64 = I64[Sp + 8]; Sp = Sp + 16; _sEV::I64 = R1; goto cFo; cFu: // RHS of True branch I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _sEU::I64; R1 = Hp - 7; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }}} This results in average 2.5% increase in binary size. By contrast, if we use `tagToEnum#` instead of `isTrue#` heap check will be placed before `case` expression and the code will be significantly shorter (this is done by a special case-on-bool optimization in the code generator - see #8317). What we would like to do here is: 1. compile case alternatives without placing heap checks inside them 2. each compiled alternative should return amount of heap it needs to allocate 3. code generator inspects amounts of heap needed by each alternative and either adds heap checks in alternatives or puts a single check before the case expression. Getting this right might be a bit tricky. 1. if all branches allocate some heap then we can just put a common heap check before the case. Note that we must allocate the higgest amount required by any of the alternatives and then alternatives that use less heap must retract the heap pointer accordingly. 2. if we have two alternatives, one of which allocates heap and the other does not, we should place the heap check only in the alternative that allocates the stack. This will solve #1498. 3. it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). If we place heap check before the `case` expression we lose optimization of recursive functions and face the problem described in #1498. If we push heap checks into branches that allocate heap then we get code duplication, i.e. the problem that we're addressing in this ticket. I guess the only way to make correct decission here is to try different aproaches and measure their performance. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8326> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #8611: nofib’s cacheprof’s allocations nondeterminisitic
by GHC 01 Jan '19

01 Jan '19

#8611: nofib’s cacheprof’s allocations nondeterminisitic -----------------------------------------+--------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark suite | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- This seems to be neither expected nor desired, and hence worth investigating: {{{ ./cacheprof +RTS -t <<ghc: 127588752 bytes, 243 GCs, 2261288/6551032 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (0.12 elapsed), 0.05 GC (0.05 elapsed) :ghc>> ./cacheprof +RTS -t <<ghc: 127392144 bytes, 242 GCs, 2261304/6551576 avg/max bytes residency (6 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.11 MUT (0.11 elapsed), 0.04 GC (0.05 elapsed) :ghc>> }}} The allocations numbers change, when they shoudn’t. Reproduced with 7.6.3 and current HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16