- ghc-tickets - Haskell.org

[GHC] #11434: Drop bzip2 in favor of xz
by GHC 18 Jan '16

18 Jan '16

#11434: Drop bzip2 in favor of xz -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- In January 2016 it was proposed that we stop providing bzip2 tarballs, instead only offering xz-compressed tarballs. This ticket is to track this process. Ben Gamari brought this proposal to the [https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-January/026123.html|mailing lists] where there was no objection. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 18 Jan '16

18 Jan '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): The gold linker only supports ELF, so it can't be used on OS X and Windows. GNU ld didn't support `--gc-sections` for PE/COFF [https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=0f088b2a9417b1d4ed597849ffa671eba25f5051 until recently], and this feature [https://ghc.haskell.org/trac/ghc/ticket/8405#comment:20 still appears to be buggy] according to olsner. So we'll need to fix those bugs in ld to make `-split-sections` work on Windows. According to the links you provided, OS X ld doesn't support `--gc- sections` at all, but maybe the `-dead_strip` option could be used. So on ELF platforms `-split-sections` should be ready to replace `-split- objs`; further testing and investigation is necessary on Windows and OS X. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 18 Jan '16

18 Jan '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > This is a general tracking bug for what is blocking us from turning on > `SplitSections` by default, implemented in #8405. Fixing this, and > mandating use of the gold linker, will help solve #11285 (split objects > make linking slow), and will make ghc-split unnecessary, mooting #9832. > > I encountered some misinformation while talking to people about this > feature, regarding whether or not this feature only supported by Apple- > style linkers (i.e. on Mac OS X)? On IRC I heard a claim made that > `--split-sections` was only supported by Mac OS X. However, olsner > pointed out that `-split-sections` on GHC was OUR reimplementation of the > feature, and likely does not work on Mac OS X. > https://github.com/snowleopard/shaking-up- > ghc/issues/153#issuecomment-171078800 A later comment mentioned that > > So, can we turn on this feature by default? Does it subsume split-objs? > Does it work on all the tier-1 platforms? It would be nice if bgamari, > olsner and co could weigh in here. Thanks! New description: This is a general tracking bug for what is blocking us from turning on `SplitSections` by default, implemented in #8405. Fixing this, and mandating use of the gold linker, will help solve #11285 (split objects make linking slow), and will make ghc-split unnecessary, mooting #9832. I encountered some misinformation while talking to people about this feature, regarding whether or not this feature only supported by Apple- style linkers (i.e. on Mac OS X)? On IRC I heard a claim made that `--split-sections` was only supported by Mac OS X. However, olsner pointed out that `-split-sections` on GHC was OUR reimplementation of the feature, and likely does not work on Mac OS X. https://github.com/snowleopard /shaking-up-ghc/issues/153#issuecomment-171078800 A later comment mentioned that So, can we turn on this feature by default? Does it subsume split-objs? Does it work on all the tier-1 platforms? It would be nice if bgamari, olsner and co could weigh in here. Thanks! Also, there are two different ways we can do this. One is we can turn it on by default in the GHC build system, so all the base libraries and GHC are built with it (but when you invoke ghc, it does NOT have split sections); the other is to have GHC always run split sections, so user code also compiles with it. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11447: Turn on SplitSections by default
by GHC 18 Jan '16

18 Jan '16

#11447: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11447#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11446: Turn on SplitSections by default
by GHC 18 Jan '16

18 Jan '16

#11446: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11446#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11402: Add Peano numbers
by GHC 18 Jan '16

18 Jan '16

#11402: Add Peano numbers -------------------------------------+------------------------------------- Reporter: strake888 | Owner: strake888 Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | 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 have seen these redefined many times now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11365: Worse performance with -O
by GHC 17 Jan '16

17 Jan '16

#11365: Worse performance with -O -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: optimization | Operating System: Unknown/Multiple performance concurrency | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The running time of the following program worsens when compiled with {{{-O}}}, and worsens more when compiled with ghc-7.10.2. {{{ #!haskell -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 3 seconds -- -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 11 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 5 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 13 seconds -- import Control.Concurrent import Control.Monad import Data.List main :: IO () main = do let x = foldl' (+) 0 [1 .. 100000000] mv <- newEmptyMVar replicateM_ 4 $ forkIO $ putMVar mv $! x nums <- replicateM 4 $ takeMVar mv print (nums :: [Integer]) }}} The following variant which doesn't share {{{x}}} improves with {{{-O}}} for ghc-7.10.2, but ghc-7.8.3 still produces a faster program. {{{ #!haskell -- /opt/ghc-7.8.3/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 10 seconds -- -- /opt/ghc-7.8.3/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 11 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -fforce-recomp test.hs -- time ./test: 18 seconds -- -- /opt/ghc-7.10.2/bin/ghc --make -threaded -O -fforce-recomp test.hs -- time ./test: 15 seconds -- import Control.Concurrent import Control.Monad import Data.IORef import Data.List main :: IO () main = do mv <- newEmptyMVar ref <- newIORef 0 replicateM_ 4 $ forkIO $ do i <- readIORef ref putMVar mv $! foldl' (+) i [1 .. 100000000] nums <- replicateM 4 $ takeMVar mv print (nums :: [Integer]) }}} Some related discussion [https://mail.haskell.org/pipermail/ghc- devs/2016-January/010904.html here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11365> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 17 Jan '16

17 Jan '16

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > If a function marked as `INLINABLE` is called indirectly through a simple > wrapper defined in a different module, specialization never happens (i.e. > none of the dictionaries are removed.) > > Here's an example where it fails. First, the simple wrapper module: > > {{{ > module Repro where > > import Data.Hashable > import Data.HashMap.Strict as M > > infixl 9 ! > (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b > m ! x = case M.lookup x m of -- lookup is INLINABLE > Just y -> y > Nothing -> error "Repro.!" > }}} > > and then the call site: > > {{{ > module Test (test) where > > import Data.HashMap.Strict as M > > import Repro > > test :: M.HashMap Int Int -> Int > test m = m ! 42 > }}} > > To compile the code you need to `cabal install unordered-containers`. The > relevant function (which is not getting specialized) from unordered- > containers is: > > {{{ > lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v > lookup k0 = go h0 k0 0 > where > h0 = hash k0 > go !_ !_ !_ Empty = Nothing > go h k _ (Leaf hx (L kx x)) > | h == hx && k == kx = Just x > | otherwise = Nothing > go h k s (BitmapIndexed b v) > | b .&. m == 0 = Nothing > | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex > b m)) > where m = mask h s > go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) > go h k _ (Collision hx v) > | h == hx = lookupInArray k v > | otherwise = Nothing > #if __GLASGOW_HASKELL__ >= 700 > {-# INLINABLE lookup #-} > #endif > }}} > > If `test` calls `lookup` directly, without using the `(!)` wrapper, > things get specialized. Manually marking `(!)` as `INLINABLE` works, but > users shouldn't have to do that. > > The core for `Repro` and `Test` is: > > {{{ > $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl > [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) > > ==================== Tidy Core ==================== > Result size = 28 > > lvl_rNZ :: [GHC.Types.Char] > [GblId] > lvl_rNZ = GHC.CString.unpackCString# "Repro.!" > > Repro.!1 :: forall b_aBU. b_aBU > [GblId, Str=DmdType b] > Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ > > Repro.! > :: forall a_atJ b_atK. > (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => > Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK > [GblId, > Arity=4, > Str=DmdType LLLL, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0 0 0 0] 70 0}] > Repro.! = > \ (@ a_aBT) > (@ b_aBU) > ($dEq_aBV :: GHC.Classes.Eq a_aBT) > ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) > (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) > (x_atM :: a_aBT) -> > case Data.HashMap.Base.lookup > @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL > of _ { > Data.Maybe.Nothing -> Repro.!1 @ b_aBU; > Data.Maybe.Just y_atN -> y_atN > } > > > [2 of 2] Compiling Test ( Test.hs, Test.o ) > > ==================== Tidy Core ==================== > Result size = 20 > > Test.test2 :: GHC.Types.Int > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 10 110}] > Test.test2 = GHC.Types.I# 42 > > Test.test1 > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> Data.Maybe.Maybe GHC.Types.Int > [GblId, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 40 0}] > Test.test1 = > Data.HashMap.Base.lookup > @ GHC.Types.Int > @ GHC.Types.Int > GHC.Classes.$fEqInt > Data.Hashable.$fHashableInt > Test.test2 > > Test.test > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> GHC.Types.Int > [GblId, > Arity=1, > Str=DmdType L, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0] 40 0}] > Test.test = > \ (m_aPx > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> > case Test.test1 m_aPx of _ { > Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; > Data.Maybe.Just y_atN -> y_atN > } > }}} > > **EDIT** > > There is yet another funny issue here. If I try to compile the modules > like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC > prints the following lines and hangs forever: > > {{{ > > [1 of 2] Compiling A ( A.hs, A.o ) > > ==================== Specialise ==================== > Result size of Specialise > = {terms: 60, types: 80, coercions: 3,048,032} > > Rec { > $dShow_a20B :: Show String > [LclId, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] > $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 > > $dPerfC1_a1Rk :: PerfC1 Int > [LclId, > Arity=1, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] > > }}} New description: If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.) Here's an example where it fails. First, the simple wrapper module: {{{ module Repro where import Data.Hashable import Data.HashMap.Strict as M infixl 9 ! (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b m ! x = case M.lookup x m of -- lookup is INLINABLE Just y -> y Nothing -> error "Repro.!" }}} and then the call site: {{{ module Test (test) where import Data.HashMap.Strict as M import Repro test :: M.HashMap Int Int -> Int test m = m ! 42 }}} To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered- containers is: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing #if __GLASGOW_HASKELL__ >= 700 {-# INLINABLE lookup #-} #endif }}} If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that. The core for `Repro` and `Test` is: {{{ $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) ==================== Tidy Core ==================== Result size = 28 lvl_rNZ :: [GHC.Types.Char] [GblId] lvl_rNZ = GHC.CString.unpackCString# "Repro.!" Repro.!1 :: forall b_aBU. b_aBU [GblId, Str=DmdType b] Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ Repro.! :: forall a_atJ b_atK. (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK [GblId, Arity=4, Str=DmdType LLLL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 70 0}] Repro.! = \ (@ a_aBT) (@ b_aBU) ($dEq_aBV :: GHC.Classes.Eq a_aBT) ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) (x_atM :: a_aBT) -> case Data.HashMap.Base.lookup @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL of _ { Data.Maybe.Nothing -> Repro.!1 @ b_aBU; Data.Maybe.Just y_atN -> y_atN } [2 of 2] Compiling Test ( Test.hs, Test.o ) ==================== Tidy Core ==================== Result size = 20 Test.test2 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [] 10 110}] Test.test2 = GHC.Types.I# 42 Test.test1 :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> Data.Maybe.Maybe GHC.Types.Int [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, Cheap=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Test.test1 = Data.HashMap.Base.lookup @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fEqInt Data.Hashable.$fHashableInt Test.test2 Test.test :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Str=DmdType L, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 40 0}] Test.test = \ (m_aPx :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> case Test.test1 m_aPx of _ { Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; Data.Maybe.Just y_atN -> y_atN } }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 17 Jan '16

17 Jan '16

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: | 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: | -------------------------------------+------------------------------------- Description changed by danilo2: Old description: > If a function marked as `INLINABLE` is called indirectly through a simple > wrapper defined in a different module, specialization never happens (i.e. > none of the dictionaries are removed.) > > Here's an example where it fails. First, the simple wrapper module: > > {{{ > module Repro where > > import Data.Hashable > import Data.HashMap.Strict as M > > infixl 9 ! > (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b > m ! x = case M.lookup x m of -- lookup is INLINABLE > Just y -> y > Nothing -> error "Repro.!" > }}} > > and then the call site: > > {{{ > module Test (test) where > > import Data.HashMap.Strict as M > > import Repro > > test :: M.HashMap Int Int -> Int > test m = m ! 42 > }}} > > To compile the code you need to `cabal install unordered-containers`. The > relevant function (which is not getting specialized) from unordered- > containers is: > > {{{ > lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v > lookup k0 = go h0 k0 0 > where > h0 = hash k0 > go !_ !_ !_ Empty = Nothing > go h k _ (Leaf hx (L kx x)) > | h == hx && k == kx = Just x > | otherwise = Nothing > go h k s (BitmapIndexed b v) > | b .&. m == 0 = Nothing > | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex > b m)) > where m = mask h s > go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) > go h k _ (Collision hx v) > | h == hx = lookupInArray k v > | otherwise = Nothing > #if __GLASGOW_HASKELL__ >= 700 > {-# INLINABLE lookup #-} > #endif > }}} > > If `test` calls `lookup` directly, without using the `(!)` wrapper, > things get specialized. Manually marking `(!)` as `INLINABLE` works, but > users shouldn't have to do that. > > The core for `Repro` and `Test` is: > > {{{ > $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl > [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) > > ==================== Tidy Core ==================== > Result size = 28 > > lvl_rNZ :: [GHC.Types.Char] > [GblId] > lvl_rNZ = GHC.CString.unpackCString# "Repro.!" > > Repro.!1 :: forall b_aBU. b_aBU > [GblId, Str=DmdType b] > Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ > > Repro.! > :: forall a_atJ b_atK. > (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => > Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK > [GblId, > Arity=4, > Str=DmdType LLLL, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0 0 0 0] 70 0}] > Repro.! = > \ (@ a_aBT) > (@ b_aBU) > ($dEq_aBV :: GHC.Classes.Eq a_aBT) > ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) > (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) > (x_atM :: a_aBT) -> > case Data.HashMap.Base.lookup > @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL > of _ { > Data.Maybe.Nothing -> Repro.!1 @ b_aBU; > Data.Maybe.Just y_atN -> y_atN > } > > > [2 of 2] Compiling Test ( Test.hs, Test.o ) > > ==================== Tidy Core ==================== > Result size = 20 > > Test.test2 :: GHC.Types.Int > [GblId, > Caf=NoCafRefs, > Str=DmdType m, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [] 10 110}] > Test.test2 = GHC.Types.I# 42 > > Test.test1 > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> Data.Maybe.Maybe GHC.Types.Int > [GblId, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 40 0}] > Test.test1 = > Data.HashMap.Base.lookup > @ GHC.Types.Int > @ GHC.Types.Int > GHC.Classes.$fEqInt > Data.Hashable.$fHashableInt > Test.test2 > > Test.test > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int > -> GHC.Types.Int > [GblId, > Arity=1, > Str=DmdType L, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, > ConLike=True, Cheap=True, Expandable=True, > Guidance=IF_ARGS [0] 40 0}] > Test.test = > \ (m_aPx > :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> > case Test.test1 m_aPx of _ { > Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; > Data.Maybe.Just y_atN -> y_atN > } > }}} New description: If a function marked as `INLINABLE` is called indirectly through a simple wrapper defined in a different module, specialization never happens (i.e. none of the dictionaries are removed.) Here's an example where it fails. First, the simple wrapper module: {{{ module Repro where import Data.Hashable import Data.HashMap.Strict as M infixl 9 ! (!) :: (Eq a, Hashable a) => M.HashMap a b -> a -> b m ! x = case M.lookup x m of -- lookup is INLINABLE Just y -> y Nothing -> error "Repro.!" }}} and then the call site: {{{ module Test (test) where import Data.HashMap.Strict as M import Repro test :: M.HashMap Int Int -> Int test m = m ! 42 }}} To compile the code you need to `cabal install unordered-containers`. The relevant function (which is not getting specialized) from unordered- containers is: {{{ lookup :: (Eq k, Hashable k) => k -> HashMap k v -> Maybe v lookup k0 = go h0 k0 0 where h0 = hash k0 go !_ !_ !_ Empty = Nothing go h k _ (Leaf hx (L kx x)) | h == hx && k == kx = Just x | otherwise = Nothing go h k s (BitmapIndexed b v) | b .&. m == 0 = Nothing | otherwise = go h k (s+bitsPerSubkey) (A.index v (sparseIndex b m)) where m = mask h s go h k s (Full v) = go h k (s+bitsPerSubkey) (A.index v (index h s)) go h k _ (Collision hx v) | h == hx = lookupInArray k v | otherwise = Nothing #if __GLASGOW_HASKELL__ >= 700 {-# INLINABLE lookup #-} #endif }}} If `test` calls `lookup` directly, without using the `(!)` wrapper, things get specialized. Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to do that. The core for `Repro` and `Test` is: {{{ $ ghc -O2 Test.hs -fforce-recomp -ddump-simpl [1 of 2] Compiling Repro ( Repro.hs, Repro.o ) ==================== Tidy Core ==================== Result size = 28 lvl_rNZ :: [GHC.Types.Char] [GblId] lvl_rNZ = GHC.CString.unpackCString# "Repro.!" Repro.!1 :: forall b_aBU. b_aBU [GblId, Str=DmdType b] Repro.!1 = \ (@ b_aBU) -> GHC.Err.error @ b_aBU lvl_rNZ Repro.! :: forall a_atJ b_atK. (GHC.Classes.Eq a_atJ, Data.Hashable.Hashable a_atJ) => Data.HashMap.Base.HashMap a_atJ b_atK -> a_atJ -> b_atK [GblId, Arity=4, Str=DmdType LLLL, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=4, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0 0 0 0] 70 0}] Repro.! = \ (@ a_aBT) (@ b_aBU) ($dEq_aBV :: GHC.Classes.Eq a_aBT) ($dHashable_aBW :: Data.Hashable.Hashable a_aBT) (m_atL :: Data.HashMap.Base.HashMap a_aBT b_aBU) (x_atM :: a_aBT) -> case Data.HashMap.Base.lookup @ a_aBT @ b_aBU $dEq_aBV $dHashable_aBW x_atM m_atL of _ { Data.Maybe.Nothing -> Repro.!1 @ b_aBU; Data.Maybe.Just y_atN -> y_atN } [2 of 2] Compiling Test ( Test.hs, Test.o ) ==================== Tidy Core ==================== Result size = 20 Test.test2 :: GHC.Types.Int [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [] 10 110}] Test.test2 = GHC.Types.I# 42 Test.test1 :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> Data.Maybe.Maybe GHC.Types.Int [GblId, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, ConLike=False, Cheap=False, Expandable=False, Guidance=IF_ARGS [] 40 0}] Test.test1 = Data.HashMap.Base.lookup @ GHC.Types.Int @ GHC.Types.Int GHC.Classes.$fEqInt Data.Hashable.$fHashableInt Test.test2 Test.test :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int -> GHC.Types.Int [GblId, Arity=1, Str=DmdType L, Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=1, Value=True, ConLike=True, Cheap=True, Expandable=True, Guidance=IF_ARGS [0] 40 0}] Test.test = \ (m_aPx :: Data.HashMap.Base.HashMap GHC.Types.Int GHC.Types.Int) -> case Test.test1 m_aPx of _ { Data.Maybe.Nothing -> Repro.!1 @ GHC.Types.Int; Data.Maybe.Just y_atN -> y_atN } }}} **EDIT** There is yet another funny issue here. If I try to compile the modules like so: `time ghc -O2 -fenable-rewrite-rules -ddump-spec B.hs` GHC prints the following lines and hangs forever: {{{ [1 of 2] Compiling A ( A.hs, A.o ) ==================== Specialise ==================== Result size of Specialise = {terms: 60, types: 80, coercions: 3,048,032} Rec { $dShow_a20B :: Show String [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $dShow_a20B = GHC.Show.$fShow[]_$s$fShow[]1 $dPerfC1_a1Rk :: PerfC1 Int [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10921: weird "optimisation levels" in man page
by GHC 17 Jan '16

17 Jan '16

#10921: weird "optimisation levels" in man page -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: manpage, | Operating System: Unknown/Multiple newcomer | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Man page shows this: {{{ Optimisation levels -O0 -O -O or -O1 -O0 -O2 -O0 -Odph }}} This looks very weird: - Why -O and -O0 listed twice? - That `or` looks weird, how do I read that? Apparently the man page is auto-generated from the user manual(thanks @int-e), and while doing that "reverse" column is also included. We should probably either ignore "reverse" column while parsing the user manual parts or somehow re-format generated man page lines. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10921> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2