December 2018 - ghc-tickets

[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] #15627: Absent unlifted bindings
by GHC 18 Jan '19

18 Jan '19

#15627: Absent unlifted bindings -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9279 #4328 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As simonpj put it in ticket:9279#comment:20: > For a long time, the worker/wrapper splitter has given up on absent > arguments of certain unlifted types: see `Literal.absentLiteralOf` and > `Note [Absent errors]` in `WwLib`. This is very annoying because it means > that we get left with functions that take a bunch of arguments they do not > use, as in this ticket (#9279). > > For lifted types T we build an absent value as a thunk of form > {{{ > aBSENT_ERROR_ID @T "Used absent value" > }}} > This does two things > A. It gives us something, of the right type, to use in place of the value > we aren't passing any more. > B. It gives an extra sanity check: if that value is ever used (a compiler > bug) we'll get a runtime error message. > > For unlifted types we don't have thunks, so we can't do this. As you can > see in `absentLiteralOf`, for some types we just make up a silly value: > e.g. for `Char#` we use `'x#'`; for `Int#` we use `0#`. > > Note, however that > > * Substituting a particular value serves purpose (A) but not purpose > (B). A compiler bug would go undetected. This is sad: e.g. #11126 > is a real bug that was detected by (B). But I see no way out. > > * It doesn't work for `Array#`, `MutVar#`, `TVar#` etc because we have > no available literal values of those types. > > So Sebastian is suggesting that we add a new literal value -- call it > a '''rubbish value''' -- which can work for any (unlifted type), > extending `Literal` something like this > {{{ > data Literal = ... > | RubbishLit Type > }}} > We need to store the type so we can still do `literalType`. > > Now > * Maybe we could get rid of `MachNullAddr` in favour of this new literal. > > * I think -- but I am not sure -- that this literal should never occur > in code generation. For example, we should never pass a rubbish value > to a function. Before then dead-code elimination should have got rid > of it I'm not 100% certain, but if this was true, it'd be a great > sanity check. > > * Yes, `Literal` has `Eq` and `Ord` -- but I'm not sure why. Try removing > them and seeing what happens! (Generally I think it'd be better to > define `eqLit` and `cmpLit` and cal them, rather than use `==` and `>`; > so much easier to grep for! > > And in fact, we do have `eqType` and `cmpType`. > > * Do we need to spit out a `RubbishLit` in the `Binary` instance. > This seems more likely, because perhaps these rubbish values can occur > in unfoldings, which are serialised as their parse tree. But > the we can just serialise the `Type`. It won't happen much. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect
by GHC 18 Jan '19

18 Jan '19

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Sometimes. Here is the thread that explains the bug: https://github.com/haskell/containers/issues/568 I originally reported this as a bug on `containers` issue tracker, but we seem to have concluded that this is probably a bug in the GHC optimizer itself. I think the shortest repro so far is this: {{{#!hs import qualified Data.Set as S main = print $ let {-# noinline f #-} f () = T2 in S.fromList [f (), f ()] data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Show, Read, Eq, Ord, Bounded, Enum) }}} which prints {{{#!hs fromList [T2,T2] }}} The person who derived this from my original repro says: > And as I said earlier, comment out the T9 constructor => prints fromList [T2] as it should. Another interesting quote: > Can confirm. Tested with ghc-8.6.1, containers-0.6.0.1 and leancheck-0.7.5 (so it does not seem to depend on the testing framework). Error occurs: > > * with ghc -O1 and -O2 (but not with -O0) > * and if data type has at least 9 elements > > So, likely a bug in ghc's optimizer. > > in some cases, input has duplicates, but not always. This is a bad one, makes GHC 8.6.1 totally unusable for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 94

[GHC] #16029: Inadequate absence analysis
by GHC 18 Jan '19

18 Jan '19

#16029: Inadequate absence analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 {{{ data S = MkS Int Int g1 :: S -> Int -> Int g1 (MkS x y) 0 = 0 g1 (MkS x y) n = g1 (MkS y x) (n-1) }}} With GHC 8.6 we get {{{ $wg1 :: S -> GHC.Prim.Int# -> GHC.Prim.Int# [Str=<S,1*H><S,1*U>] $wg1 = \ (w_s2oH :: S) (ww_s2oL :: GHC.Prim.Int#) -> case w_s2oH of { MkS x_s2pz y_s2pA -> case ww_s2oL of ds_X2nb { __DEFAULT -> Foo.$wg1 (Foo.MkS y_s2pA x_s2pz) (GHC.Prim.-# ds_X2nb 1#); 0# -> 0# }} g1 :: S -> Int -> Int [Str=<S,1*H><S(S),1*U(1*U)>m] g1 = \ (w_s2oH :: S) (w1_s2oI :: Int) -> case w_s2oH of w2_X2pG { MkS ipv_s2p2 ipv1_s2p3 -> case w1_s2oI of { GHC.Types.I# ww1_s2oL -> case Foo.$wg1 w2_X2pG ww1_s2oL of ww2_s2oP { __DEFAULT -> GHC.Types.I# ww2_s2oP }}} }}} What terrible code! We evaluate the S argument in the wrapper, and box and unbox it every time around the loop, even though it is never ultimately used. Here's what happens if the arguments are banged: {{{ data T = MkT !Int !Int g2 :: T -> Int -> Int g2 (MkT x y) 0 = 0 g2 (MkT x y) n = g2 (MkT y x) (n-1) }}} We get {{{ $wg2 GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [Str=<L,1*U><L,1*U><S,1*U>] Foo.$wg2 = \ (ww_s2ow :: GHC.Prim.Int#) (ww1_s2ox :: GHC.Prim.Int#) (ww2_s2oB :: GHC.Prim.Int#) -> case ww2_s2oB of ds_X2n0 { __DEFAULT -> Foo.$wg2 ww1_s2ox ww_s2ow (GHC.Prim.-# ds_X2n0 1#); 0# -> 0# } g2 :: T -> Int -> Int [Str=<S(SS),1*U(1*U,1*U)><S(S),1*U(1*U)>m ] g2 = \ (w_s2os :: T) (w1_s2ot :: Int) -> case w_s2os of { MkT ww1_s2ow ww2_s2ox -> case w1_s2ot of { GHC.Types.I# ww4_s2oB -> case Foo.$wg2 ww1_s2ow ww2_s2ox ww4_s2oB of ww5_s2oF { __DEFAULT -> GHC.Types.I# ww5_s2oF }}} }}} Still terrible. We pass the two components around the loop before discarding them at the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16029> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #16042: T13031 doesn't get run
by GHC 18 Jan '19

18 Jan '19

#16042: T13031 doesn't get run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simon wrote noting that two tests in `stranal/should_compile` didn't appear to be run in his testing. I have been able to reproduce this. A few observations: * There is a `setTestOpts( only_ways(['optasm']) )` at the top of `stranal/should_compile/test.T` * in a `validate` build `T13031` is skipped when run with: * `make test TEST=T13031 WAY=normal` * `make test TEST=T13031 WAY=optasm` * `make slowtest TEST=T13031 WAY=normal` * `make slowtest TEST=T13031 WAY=optasm` * When the `setTestOpts` call is commented out `T13031` is * skipped with `make test TEST=T13031 WAY=optasm` * run with `make test TEST=T13031 WAY=normal` * `optasm` is in the `config.run_ways` list I suspect what is happening here is that the `optasm` way is not being run To be continued... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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

17 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