August 2016 - ghc-tickets

Re: [GHC] #7283: Specialise INLINE functions
by GHC 04 Aug '16

04 Aug '16

#7283: Specialise INLINE functions -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7283#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7803: Superclass methods are left unspecialized
by GHC 04 Aug '16

04 Aug '16

#7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7803#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7829: make better/more robust loopbreaker choices
by GHC 04 Aug '16

04 Aug '16

#7829: make better/more robust loopbreaker choices -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7829#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining
by GHC 04 Aug '16

04 Aug '16

#8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining ------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- I just remembered an old idea I put to the GHC user's list [http://www .mail-archive.com/glasgow-haskell-users(a)haskell.org/msg22119.html here], and thought I should present it here. As I understand it GHC inlines inlines only after a function is fully applied with respect to the syntactic left-hand side, so in order to control inlining and sharing, we sometimes see strange things like: {{{ {-# INLINE foo #-} foo :: a -> b -> c foo a = \b -> ... }}} It would be nice to be able to define the function syntactically in the way that's the most clear (e.g. in pointfree style, etc.) and specify at what point to inline something like this: {{{ foo :: a -> {-# INLINE #-} b -> c foo a b = ... -- or: foo = ... }}} ...which tells the compiler to inline after applying the arguments to the left of the pragma, and GHC would do whatever trivial (I assume?) eta- conversion was required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[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] #12454: Cross-module specialisation of recursive functions
by GHC 04 Aug '16

04 Aug '16

#12454: Cross-module specialisation of recursive functions -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Inlining | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is common for library authors to write overloaded functions but in doing so they cause a performance penalty for their consumers as GHC refuses the specialise such functions across modules. For example, {{{#!hs {-# language FlexibleContexts #-} module M where import Control.Monad.IO.Class import Control.Monad.Reader hello :: (MonadIO m, MonadReader Int m) => Int -> m () hello n = do m <- ask case m `mod` n == 0 of True -> liftIO $ print "helloo" False -> hello (n-1) }}} Using `hello` in a client module, we would like to optimise away the explicit dictionary passing once we specialise `hello` to a specific monad stack. {{{#!hs import M import Control.Monad.Reader import M (hello) main :: IO () main = runReaderT (hello 128) 42 }}} However, as `hello` is recursive its unfolding was not included in the interface file. As a result, the specialisation can't take place which leaves us with less efficient code. The solution to this is mark `hello` as `INLINABLE`. Once we do this the unfolding of `hello` is included in the interface file even though `hello` will never be inlined as it is self-recursive and hence the loop-breaker. Once included in the interface file, GHC can properly specialise `hello` and produce optimal code. An aside, it is quite strange to mark such a recursive definition as `INLINABLE` to get this behaviour as you know it will never be inlined. It would perhaps be better to have a better named pragma which ensured unfoldings were placed in interface files. This ticket is to track the behaviour of these types of definitions which are very common in the wild. A proposed solution on #5928 was to add a flag to always mark overloaded functions as inlinable to make sure these specialisations can take place. This is something which I am planning to implement in order to see what the consequences are in terms of performance and interface file sizes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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