June 2018 - ghc-tickets

[GHC] #14976: WebAssembly support
by GHC 19 Jan '19

19 Jan '19

#14976: WebAssembly support -------------------------------------+------------------------------------- Reporter: sven | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: wasm, | Operating System: Unknown/Multiple webassembly | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I would like to suggest adding a wasm backend to GHC. PureScript is also offering something similar. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13452: Lock .tix file
by GHC 19 Jan '19

19 Jan '19

#13452: Lock .tix file -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Code Coverage | 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 HPC documentation [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h… #caveats-and-shortcomings-of-haskell-program-coverage warns] that > HPC does not attempt to lock the `.tix` file, so multiple concurrently running binaries in the same directory will exhibit a race condition. This sounds like something that shouldn't be too terribly hard to fix, once we determine exactly how we want to deal with contention. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13452> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[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] #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown
by GHC 18 Jan '19

18 Jan '19

#13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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 was investigating some benchmarks and I noticed some odd results if I duplicated one of my tests. Reproduction: https://github.com/mpickering/probable-eureka Looking at the core, it seems that repeating the definition means that one of the key functions doesn't get specialised as expected which leads to a much slower program. Observe that in the first two benchmarks there is a worker function `go :: Int# -> Int -> ReaderT Int (StateT Int Identity Int` but in the third benchmark this is specialised to `$sgo :: Int# -> Int -> Int -> Int# -> Int# -> Identity (Int, Int)`. Removing the duplicate benchmark means that specialisation happens properly in the first case as well. The proper specialisation also happens in 8.0.2. This causes the first two cases to be 6x slower than the last case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15056: Wrappers inlined too late
by GHC 18 Jan '19

18 Jan '19

#15056: Wrappers inlined too late -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider these two modules {{{ module Foo where test :: Int -> Bool test 0 = True test n = test (n-1) foo :: Foldable t => Int -> t Int -> Int foo n xs | test n = foldr (+) n xs | otherwise = n+7 }}} and {{{ module Bar where import Foo blam x = f 3 [1..x] }}} If we simply inline `foo` into `blam`, we get `foldr/build` fusion. And that is exactly what happens if you compile `Foo` with `-fno-strictness`. But what actually happens is * When compiling `Foo`, strictness analysis does worker/wrapper for `foo`. * The wrapper currently gets an aciviation of "active only in phase 0"; see `Note [Wrapper activation]` in `WorkWrap`. * So `foo` is ultimately inlined (actually its worker is inlined too) but too late for fusion to take place. This is bad: optimising `Foo` makes the overall runtime increase. I have seen other examples of this. The general pattern is: * Without worker/wrapper, a function `f` may inline, which exposes opportunities for functions in its body to participate in rule rewrites * With worker/wrapper, no inlining happens until phase 0; and that is too late for the rules to fire. Obvious thought: allow wrappers from strictness analysis to inline earlier. I'll try that. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15056> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[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] #14816: Missed Called Arity opportunity?
by GHC 18 Jan '19

18 Jan '19

#14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- When I compile {{{#!hs test :: (a -> a -> a) -> Int -> a -> HashMap Int a -> HashMap Int a test f k a m = insertModifying a (blink (f a)) k m blink :: (a -> b) -> a -> (# b #) -- Or blink g = \a -> (# g a #) ; it makes no difference. blink g a = (# g a #) }}} I get {{{ test = \ (@ a_a9o3) (f_a7iP :: a_a9o3 -> a_a9o3 -> a_a9o3) (k_a7iQ :: Int) (a1_a7iR :: a_a9o3) (m_a7iS :: HashMap Int a_a9o3) -> case k_a7iQ of { GHC.Types.I# ww1_sa1Z -> RULES.$w$sinsertModifying @ a_a9o3 a1_a7iR (let { g_s9E1 [Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3 [LclId] g_s9E1 = f_a7iP a1_a7iR } in \ (a2_a7iU :: a_a9o3) -> (# g_s9E1 a2_a7iU #)) ww1_sa1Z m_a7iS } }}} We build `g_s9E1 = f_a7iP a1_a7iR` for no apparent reason. Trouble persists into STG: {{{ RULES.test :: forall a. (a -> a -> a) -> GHC.Types.Int -> a -> Data.HashMap.Base.HashMap GHC.Types.Int a -> Data.HashMap.Base.HashMap GHC.Types.Int a [GblId, Arity=4, Str=<L,1*C1(C(U))><S(S),1*U(U)><L,U><S,1*U>, Unf=OtherCon []] = [] \r [f_saiX k_saiY a1_saiZ m_saj0] case k_saiY of { GHC.Types.I# ww1_saj2 [Occ=Once] -> let { g_saj3 [Occ=OnceL!, Dmd=<L,C(U)>] :: a_a9o3 -> a_a9o3 [LclId] = [f_saiX a1_saiZ] \u [] f_saiX a1_saiZ; } in let { sat_saj6 [Occ=Once] :: a_a9o3 -> (# a_a9o3 #) [LclId] = [g_saj3] \r [a2_saj4] let { sat_saj5 [Occ=Once] :: a_a9o3 [LclId] = [g_saj3 a2_saj4] \u [] g_saj3 a2_saj4; } in Unit# [sat_saj5]; } in RULES.$w$sinsertModifying a1_saiZ sat_saj6 ww1_saj2 m_saj0; }; }}} `insertModifying` uses its function argument at most once, so there is no possible benefit to this partial application. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15226: GHC doesn't know that seq# produces something in WHNF
by GHC 18 Jan '19

18 Jan '19

#15226: GHC doesn't know that seq# produces something in WHNF -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- {{{#!hs data Str a = Str !a bar :: Maybe a -> IO (Str (Maybe a)) bar x = do x' <- evaluate x pure (Str x') }}} This compiles to {{{#!hs Test.bar1 = \ (@ a_a3Ld) (x_a3Ah :: Maybe a_a3Ld) (s_i3Nz :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.seq# @ (Maybe a_a3Ld) @ GHC.Prim.RealWorld x_a3Ah s_i3Nz of { (# ipv_i3NC, ipv1_i3ND #) -> (# ipv_i3NC, Test.$WStr @ (Maybe a_a3Ld) ipv1_i3ND #) } }}} We suspend the application of `$WStr` to `ipv1_i3ND`, when all we actually need to do is apply `Str` directly. We could work around this in `base` by defining {{{#!hs evaluate x = IO $ \s -> case seq# x s of (# s', !x' #) -> (# s', x' #) }}} but that seems more than a little bit silly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15226> 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