July 2016 - ghc-tickets

[GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE
by GHC 04 Aug '16

04 Aug '16

#8589: Bad choice of loop breaker with INLINABLE/INLINE ------------------------------+-------------------------------------------- Reporter: | Owner: NickSmallbone | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- Take the following program, which defines a pair of lists recursively: {{{ module Test(xs, ys) where pair :: ([Bool], [Bool]) pair = (False:xs, True:ys) where (xs, ys) = pair (xs, ys) = pair }}} GHC is clever enough to disentangle {{{xs}}} from {{{ys}}} and with {{{-ddump-simpl -O}}} I get: {{{ Rec { xs [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] xs = : False xs end Rec } Rec { ys [Occ=LoopBreaker] :: [Bool] [GblId, Caf=NoCafRefs, Str=DmdType] ys = : True ys end Rec } }}} However, if I mark {{{pair}}} as {{{INLINABLE}}} or {{{INLINE}}} (it doesn't matter which), I get much worse code where {{{xs}}} and {{{ys}}} go through {{{pair}}}: {{{ Rec { pair [InlPrag=INLINABLE[ALWAYS], Occ=LoopBreaker] :: ([Bool], [Bool]) [GblId, Str=DmdType m, Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 50 30 Tmpl= (: False (case pair of _ { (xs1_Xf6 [Occ=Once], _) -> xs1_Xf6 }), : True (case pair of _ { (_, ys1_Xf6 [Occ=Once]) -> ys1_Xf6 }))}] pair = (a1_rgo, a_rgn) ys_ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] ys_ys = case pair of _ { (xs1_XeW, ys1_Xf7) -> ys1_Xf7 } a_rgn :: [Bool] [GblId, Str=DmdType] a_rgn = : True ys_ys xs_xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 0}] xs_xs = case pair of _ { (xs1_XeW, ys1_XeS) -> xs1_XeW } a1_rgo :: [Bool] [GblId, Str=DmdType] a1_rgo = : False xs_xs end Rec } ys :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] ys = ys_ys xs :: [Bool] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(unsat_ok=True,boring_ok=True)}] xs = xs_xs }}} It seems that GHC chooses {{{pair}}} as the loop breaker, which stops the simplifier in its tracks. It might seem a bit silly to mark {{{pair}}} as {{{INLINE}}}, since it's not mutually recursive. The function I really had was polymorphic with a typeclass constraint, and I wrote {{{INLINABLE}}} to get it specialised at its call site. (Also, {{{pair}}} is mutually recursive in the Core, so you would expect GHC to avoid using it as a loop breaker if I mark it {{{INLINE}}}.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8662: GHC does not inline cheap inner loop when used in two places
by GHC 04 Aug '16

04 Aug '16

#8662: GHC does not inline cheap inner loop when used in two places ------------------------------+-------------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When I made a Criterion benchmark of Neil Michell's "Tight Inner Loop" blog post (http://neilmitchell.blogspot.co.uk/2014/01/optimising-haskell- for-tight-inner-loop.html), I noticed that GHC 7.6.3 will not inline the performance-critical function when it's called from two different places (inside the same module). {{{ break0_2pleaseinline :: (Char -> Bool) -> ByteString0 -> (ByteString, ByteString0) break0_2pleaseinline f (BS0 bs) = (BS.unsafeTake i bs, BS0 $ BS.unsafeDrop i bs) where i = Internal.inlinePerformIO $ BS.unsafeUseAsCString bs $ \ptr -> do let start = castPtr ptr :: Ptr Word8 let end = go start return $! Ptr end `minusPtr` start go s@(Ptr a) | c == '\0' || f c = a | otherwise = go $ inc s where c = chr s versionInl1 :: ByteString0 -> (ByteString, ByteString0) versionInl1 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') versionInl2 :: ByteString0 -> (ByteString, ByteString0) versionInl2 str = break0_2pleaseinline test str where test x = x <= '$' && (x == ' ' || x == '\r' || x == '\n' || x == '$') }}} Full code here: https://github.com/nh2/inner-loop- benchmarks/blob/6715d1e9946d6b5e6d9bb53203982ed3d2ed32ff/Bench.hs#L166. {{{break0_2pleaseinline}}} does not get inlined, which makes {{{versionInl1}}} and {{{versionInl2}}} over 4 times slower than when inlined. The inlining doens't happen, not even with {{{-O2}}} and {{{-O3}}}, only an {{{INLINE}}} pragma will move GHC to do it. If I was a compiler, I would so inline that function! I am surprised that GHC doesn't decide to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8662> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8814: 7.8 optimizes attoparsec improperly
by GHC 04 Aug '16

04 Aug '16

#8814: 7.8 optimizes attoparsec improperly ------------------------------+-------------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime performance bug (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- {{{ #!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import qualified Data.Attoparsec.Text as A import Data.Text (Text) import qualified Data.Text as T testParser :: Text -> Either String Int testParser f = fmap length . A.parseOnly (many (A.char 'b' <|> A.anyChar)) $ f main :: IO () main = print . testParser $ T.replicate 50000 "a" }}} On GHC 7.6.3 with `-O2`: {{{ real 0m0.062s user 0m0.022s sys 0m0.007s }}} On GHC 7.8 tip with `-O2`: {{{ real 0m12.700s user 0m12.504s sys 0m0.165s }}} On GHC 7.6.3 with `-O0`: {{{ real 0m0.077s user 0m0.025s sys 0m0.007s }}} On GHC 7.8 tip with `-O0`: {{{ real 0m0.055s user 0m0.026s sys 0m0.007s }}} This seems to be related to the use of `<|>`; if I change the program so that the second branch (`A.anyChar`) is never taken, 7.8 behavior is roughly the same as 7.6 under any optimization level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #9798: Frustrating behaviour of the INLINE pragma
by GHC 03 Aug '16

03 Aug '16

#9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- So I have a function "a", which uses another function "b" from another module. * Step 1. I benchmark its performance and get 250ns. * Step 2. I go and put the "INLINE" pragma on the function "b", run the benchmark again and get 500ns. That is twice as long. * Step 3. I go and add an explicit invocation of the [http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC- Exts.html#v:inline inline] function over function "b" in function "a" and finally get the desired optimization: 208ns. You can reproduce the issue by executing {{{cabal bench decoding --benchmark-options=numeric}}} after cloning the trees of the following commits: * [https://github.com/nikita-volkov/postgresql- binary/commit/31e08b4f6887445c28118d25f9da808e7ca9fc86 Step 1] * [https://github.com/nikita-volkov/postgresql- binary/commit/8f29b8daebc3161dc0fa35fbd70d3f3305370a4e Step 2] * [https://github.com/nikita-volkov/postgresql- binary/commit/3d3e4378bcd8ea85cda868d6a4bf07a76a9cad2c Step 3] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10710: More self-explanatory pragmas for inlining phase control
by GHC 03 Aug '16

03 Aug '16

#10710: More self-explanatory pragmas for inlining phase control -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Eventually implement [[Proposal/SelfExplinatoryInlinePragmas]]. And while at it: Extend the docs where they say “You shouldn't ever need to do this, unless you're very cautious about code size.” -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10766: user manual: INLINE's interaction with optimization levels is not clear
by GHC 03 Aug '16

03 Aug '16

#10766: user manual: INLINE's interaction with optimization levels is not clear -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- user manual: INLINE's interaction with optimization levels is not clear From the user manual it's not possible to say how should INLINE and actual inlining behavior should interact with optimization levels. What the user manuals says: - Without INLINE GHC tries to inline depending on size of definitions and current optimization level(user manual says -O is needed, but can we assume that for any inlining to be done we need at least -O? Because I have an example in which inlining is happening even with -O0). - With INLINE GHC tries hard to inline. But it doesn't say which optimization level is needed. I think we should add word or two about this. Does anyone know the answer here? My guess is: Even though INLINE makes sure GHC saves RHS of the definition in .hi files to be able to inline later, optimization levels still have an effect on deciding whether to inline or not. Because some INLINEd RHSs may be too big in which case it may decide not to inline with -O1 but inline with -O2 etc. Furthermore, without -O, GHC doesn't mark definitions as INLINE. But if we have INLINEd definitions and compiling a code with -O0, it may still inline those definitions, because there are two different mechanisms to decide whether to mark as INLINE and whether to inline the RHS, and while without -O GHC doesn't mark anything as INLINE, it can still inline previously marked definitions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200
by GHC 03 Aug '16

03 Aug '16

#11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new 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: 10527 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12274: GHC panic: simplifier ticks exhausted
by GHC 03 Aug '16

03 Aug '16

#12274: GHC panic: simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While compiling a project, I ran into this: {{{ Preprocessing library stache-0.1.0... [1 of 6] Compiling Text.Mustache.Type ( Text/Mustache/Type.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Type.o ) [.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/cabal_macros.h changed] [2 of 6] Compiling Text.Mustache.Parser ( Text/Mustache/Parser.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Parser.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op HEq_sc To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 189602 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code is available here: https://github.com/stackbuilders/stache This only happens with GHC 8.0, with 7.10 it just takes forever (which should be a known issue, with 7.8 it's much faster), but nevertheless finishes. With `-fsimpl-tick-factor=150` the build suceeded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8473: Generate table of cost-centre numbers with source locations
by GHC 01 Aug '16

01 Aug '16

#8473: Generate table of cost-centre numbers with source locations ------------------------------------+------------------------------------- Reporter: lars_e_krueger | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | 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: 7105 | ------------------------------------+------------------------------------- .prof files contain a cost centre number, which I assume is cc_key from CostCentre.lhs. It would be immensely helpful if the compiler creates a simpe table. This way, one could look up the number in .prof, check the table and the exact source location. It would also help with #7105, I think. Suggestion for the format: {{{ no. file begin end 1 main.hs 127:7 128:14 }}} Meaning: Cost centre 1 is in file main.hs, begins at line 127, character 7 and ends at line 128, character 14. If somebody points me in the right direction, and the whole thing is not too complicated, I can try my hand at implementing it myself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12391: LANGUAGE CPP messes up parsing when backslash like \\ is at end of line (eol)
by GHC 31 Jul '16

31 Jul '16

#12391: LANGUAGE CPP messes up parsing when backslash like \\ is at end of line (eol) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: CPP | 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 {-# LANGUAGE CPP #-} import Data.List as List main = putStrLn $ "not nice" List.\\ "hot mice" }}} fails with recent ghc (I tried >= 7.8). {{{ Not in scope: ‘List.\’ }}} This problem occurred in a larger context, see https://travis-ci.org/agda/agda/jobs/144514733 It can be traced back to the use of cpp as preprocessor: {{{ $ cpp BackslashAtEOL.hs # 1 "BackslashAtEOL.hs" # 1 "<built-in>" 1 # 1 "<built-in>" 3 # 328 "<built-in>" 3 # 1 "<command line>" 1 # 1 "<built-in>" 2 # 1 "BackslashAtEOL.hs" 2 {-# LANGUAGE CPP #-} import Data.List as List main = putStrLn $ "not nice" List.\ "hot mice" }}} In contrast, cpphs would work correctly here: {{{ $ cpphs BackslashAtEOL.hs #line 1 "BackslashAtEOL.hs" {-# LANGUAGE CPP #-} import Data.List as List main = putStrLn $ "not nice" List.\\ "hot mice" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2