January 2016 - ghc-tickets

[GHC] #9960: Performance problem with TrieMap
by GHC 07 Jan '16

07 Jan '16

#9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Looking at #9805 reminded me. When investigating the performance of #9872 I found a major performance hole in `TrieMap`. Suppose we have a handful H of entries in a `TrieMap`, each with a very large key, size K. If you fold over such a `TrieMap` you'd expect time O(H). That would certainly be true of an association list! But with `TrieMap` we actually have to navigate down a long singleton structure to get to the elements, so it takes time O(K*H). This is pretty bad. In test `T9872` I found that 90% of compile time was spent in `TrieMap` as we repeatedly built, folded, and then rebuilt `TrieMap`s. I fixed that by keeping smaller `TrieMap`s, but the underlying problem remains. The point of a `TrieMap` is that you need to navigate to the point where only one key remains, and then things should be fast. So I think that `TypeMap`, say, should look like {{{ data TypeMap a = EmptyTM | SingletonTM Type a | TM { tm_var :: VarMap a , tm_app :: TypeMap (TypeMap a) , tm_fun :: TypeMap (TypeMap a) , tm_tc_app :: NameEnv (ListMap TypeMap a) , tm_forall :: TypeMap (BndrMap a) , tm_tylit :: TyLitMap a } }}} The `SingletonTM` means that, once you are down to a single (key,value) pair, you stop and just use `SingletonTM`. Tiresomely, because of the deBruijn thing, it'd need to be {{{ ... | SingletonTM (CMEnv, Type) a ... }}} and we'd need an auxiliary function for equality: {{{ eqTypeModuloDeBruijn :: (CMEnv, Type) -> (CEnv, Type) -> Bool }}} But that's not hard. Very similar to the way `RnEnv2` works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] Batch modify: #10558, #10567, #10742, #10540, #10753, #10609, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10558, #10567, #10742, #10540, #10753, #10609, #10721, #10615, #10704, #10706, #10694, #10586, #10134, #8253, #10522 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10558%2C10567%2C10742%2C10540%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10744: Allow oneShot to work with unboxed types
by GHC 07 Jan '16

07 Jan '16

#10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | 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 Revisions: | -------------------------------------+------------------------------------- Currently `oneShot` requires that both the argument type and the return type of the given function have the kind `*`. It would be nice if I could use unlifted types there. The following program demonstrates this: {{{#!hs {-# LANGUAGE MagicHash #-} module Foo where import GHC.Exts import GHC.Magic f0 :: Int -> Int f0 = oneShot $ \n -> n -- OK f1 :: Int# -> Int f1 = oneShot $ \n# -> I# n# -- Error, the argument type is unlifted f2 :: Int -> Int# f2 = oneShot $ \(I# n#) -> n# -- Error, the result type is unlifted }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] Batch modify: #10837, #10580, #9912, #9782, #9855, #9710, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10837, #10580, #9912, #9782, #9855, #9710, #10849, #10486, #8596, #10775, #10762, #10805 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10837%2C10580%2C9912%2C9782%2C9855…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10900, #10622, #10734, #9591, #11038, #11010, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10900, #10622, #10734, #9591, #11038, #11010, #10979, #10149, #10267, #10714, #10939, #10868, #365, #10926, #10777, #10475, #10907, #10867 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10900%2C10622%2C10734%2C9591%2C110…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11027: GHC API panic (evaluated the place holder for a PostTcType)
by GHC 07 Jan '16

07 Jan '16

#11027: GHC API panic (evaluated the place holder for a PostTcType) -------------------------------------+------------------------------------- Reporter: rubik | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.4 Keywords: undefined, | Operating System: Linux place holder, posttctype | Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The same code that works for GHC 7.10.2 blows up on GHC 7.8.4, with errors like {{{ test/ArgonSpec.hs:104: (best-effort) 6) Argon.analyze accounts for && operator uncaught exception: GhcException (argon-test: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): fixity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ) test/ArgonSpec.hs:106: (best-effort) 7) Argon.analyze counts everything in a real example uncaught exception: GhcException (argon-test: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Evaluated the place holder for a PostTcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ) }}} The responsible module is [https://github.com/rubik/argon/blob/master/src/Argon/Visitor.hs] and in particular (I think): {{{ visitExp :: Exp -> Int visitExp (GHC.HsIf {}) = 1 visitExp (GHC.HsMultiIf _ alts) = length alts - 1 visitExp (GHC.HsLamCase _ alts) = length (GHC.mg_alts alts) - 1 visitExp (GHC.HsCase _ alts) = length (GHC.mg_alts alts) - 1 visitExp _ = 0 visitOp :: Exp -> Int visitOp (GHC.OpApp _ (GHC.L _ (GHC.HsVar op)) _ _) = case getName op of "||" -> 1 "&&" -> 1 _ -> 0 visitOp _ = 0 }}} somehow, even if I use wildcards, the first arguments of the type constructors gets evaluated and since it's undefined GHC crashes. What am I supposed to do? The documentation does not say anything on the matter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] Batch modify: #10039, #10318, #11232, #11237, #10636, #11185, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10039, #10318, #11232, #11237, #10636, #11185, #9632, #10819, #11053, #11194, #10785, #9017, #9389, #11192, #11187, #6119, #11155, #9706, #11016, #11148, #11144, #10896, #10839, #11132, #10836, #11136, #11105, #11112, #11119, #10970, #9651 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10039%2C10318%2C11232%2C11237%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10625, #11292, #10716, #10361, #10927, #10846, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10625, #11292, #10716, #10361, #10927, #10846, #11122, #11283, #11233, #11255, #10619, #10589, #10432, #11039, #10897, #10362, #11137, #11265, #11274, #10426, #10982, #11225, #10697, #5217 by thomie: milestone to 8.0.1 Action: leave -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10625%2C11292%2C10716%2C10361%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10289, #10750, #9430, #10359, #10129
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10289, #10750, #9430, #10359, #10129 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10289%2C10750%2C9430%2C10359%2C101…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults
by GHC 07 Jan '16

07 Jan '16

#8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------+------------------------------------- I built ghc-7.8.1 RC2 on ppc Fedora 21 Development with ghc-7.6.3. When I try to run dynamically linked "helloworld", it segfaults. I don't have direct access yet to a ppc box to investigate further. I guess something about the use of shared libraries on ppc is not working properly. {{{ $ cat > hello.hs main = putStrLn "hi" $ ghc -dynamic hello.hs $ ./hello Segmentation fault (core dumped) ./hello }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6