April 2017 - ghc-tickets

[GHC] #13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts
by GHC 25 Apr '17

25 Apr '17

#13549: GHC 8.2.1's typechecker rejects code generated by singletons that 8.0 accepts -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently attempted to upgrade `singletons` to use GHC 8.2.1, but was thwarted when GHC's typechecker rejected code that was generated by Template Haskell. I was able to put all of this code in a single module (which I've attached), but sadly, it's 1367 lines long. What's important is that GHC 8.0.1 and 8.0.2 accept this code, but neither 8.2.1-rc1 nor HEAD do. Here is the error message you get, in its full glory: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170403: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:1328:59: error: • Couldn't match type ‘c69895866216793215480’ with ‘[a_a337f]’ ‘c69895866216793215480’ is untouchable inside the constraints: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) bound by the type signature for: lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) (r_a33fq :: [[a_a337f]]). (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) => Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) at Bug.hs:(1289,35)-(1294,157) Expected type: Sing t -> Sing t1 -> Sing t2 -> Sing (((Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO @@ t) @@ t1) @@ t2) Actual type: Sing t -> Sing t1 -> Sing t2 -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) • In the second argument of ‘singFun3’, namely ‘sInterleave'’ In the first argument of ‘applySing’, namely ‘((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')’ In the first argument of ‘applySing’, namely ‘((applySing ((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')) ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ • Relevant bindings include sX_6989586621679737266 :: Sing (Let6989586621679737265X_6989586621679737266Sym6 xs0_a33a0 t_a33aL ts_a33aM is_a33aO xs_a33fp r_a33fq) (bound at Bug.hs:1321:41) r_a33iK :: Sing r_a33fq (bound at Bug.hs:1295:57) xs_a33iJ :: Sing xs_a33fp (bound at Bug.hs:1295:48) lambda_a33iH :: Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) (bound at Bug.hs:1295:35) sR :: Sing arg_a33hi (bound at Bug.hs:1287:45) sXs :: Sing arg_a33hh (bound at Bug.hs:1287:41) sInterleave' :: forall (arg_a33he :: TyFun [a_a337f] c69895866216793215480 -> *) (arg_a33hf :: [a_a337f]) (arg_a33hg :: [c69895866216793215480]). Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33he) arg_a33hf) arg_a33hg) (bound at Bug.hs:1166:29) lambda_a33ha :: Sing t_a33aL -> Sing ts_a33aM -> Sing is_a33aO -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) arg_a33h1) (bound at Bug.hs:1153:23) sTs :: Sing n_a1kQd (bound at Bug.hs:1143:34) sT :: Sing n_a1kQc (bound at Bug.hs:1143:31) lambda_a33gY :: Sing xs0_a33a0 -> Sing (Apply PermutationsSym0 t_a33gX) (bound at Bug.hs:1127:11) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 1328 | sInterleave')) | ^^^^^^^^^^^^ Bug.hs:1328:59: error: • Could not deduce: Let6989586621679736980Interleave' xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 ~ Let6989586621679736980Interleave' xs0_a33a0 t_a33aL ts_a33aM is_a33aO t t1 t2 from the context: t_a33gX ~ xs0_a33a0 bound by the type signature for: lambda_a33gY :: forall (xs0_a33a0 :: [a_a337f]). t_a33gX ~ xs0_a33a0 => Sing xs0_a33a0 -> Sing (Apply PermutationsSym0 t_a33gX) at Bug.hs:(1122,11)-(1126,67) or from: arg_a33h0 ~ (n_a1kQc : n_a1kQd) bound by a pattern with constructor: SCons :: forall a_11 (z_a1kQb :: [a_11]) (n_a1kQc :: a_11) (n_a1kQd :: [a_11]). z_a1kQb ~ (n_a1kQc : n_a1kQd) => Sing n_a1kQc -> Sing n_a1kQd -> Sing z_a1kQb, in an equation for ‘sPerms’ at Bug.hs:1143:25-36 or from: (arg_a33h0 ~ Apply (Apply (:$) t_a33aL) ts_a33aM, arg_a33h1 ~ is_a33aO) bound by the type signature for: lambda_a33ha :: forall (t_a33aL :: a_a337f) (ts_a33aM :: [a_a337f]) (is_a33aO :: [a_a337f]). (arg_a33h0 ~ Apply (Apply (:$) t_a33aL) ts_a33aM, arg_a33h1 ~ is_a33aO) => Sing t_a33aL -> Sing ts_a33aM -> Sing is_a33aO -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) arg_a33h1) at Bug.hs:(1145,23)-(1152,117) or from: (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) bound by the type signature for: lambda_a33iH :: forall (xs_a33fp :: [a_a337f]) (r_a33fq :: [[a_a337f]]). (arg_a33hh ~ xs_a33fp, arg_a33hi ~ r_a33fq) => Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) at Bug.hs:(1289,35)-(1294,157) Expected type: Sing t -> Sing t1 -> Sing t2 -> Sing (((Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO @@ t) @@ t1) @@ t2) Actual type: Sing t -> Sing t1 -> Sing t2 -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) t) t1) t2) The type variable ‘c69895866216793215480’ is ambiguous Use -fprint-explicit-kinds to see the kind arguments • In the second argument of ‘singFun3’, namely ‘sInterleave'’ In the first argument of ‘applySing’, namely ‘((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')’ In the first argument of ‘applySing’, namely ‘((applySing ((singFun3 (Proxy :: Proxy (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO))) sInterleave')) ((singFun1 (Proxy :: Proxy IdSym0)) sId))’ • Relevant bindings include sX_6989586621679737266 :: Sing (Let6989586621679737265X_6989586621679737266Sym6 xs0_a33a0 t_a33aL ts_a33aM is_a33aO xs_a33fp r_a33fq) (bound at Bug.hs:1321:41) r_a33iK :: Sing r_a33fq (bound at Bug.hs:1295:57) xs_a33iJ :: Sing xs_a33fp (bound at Bug.hs:1295:48) lambda_a33iH :: Sing xs_a33fp -> Sing r_a33fq -> Sing (Apply (Apply (Let6989586621679736980InterleaveSym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33hh) arg_a33hi) (bound at Bug.hs:1295:35) sR :: Sing arg_a33hi (bound at Bug.hs:1287:45) sXs :: Sing arg_a33hh (bound at Bug.hs:1287:41) sInterleave' :: forall (arg_a33he :: TyFun [a_a337f] c69895866216793215480 -> *) (arg_a33hf :: [a_a337f]) (arg_a33hg :: [c69895866216793215480]). Sing arg_a33he -> Sing arg_a33hf -> Sing arg_a33hg -> Sing (Apply (Apply (Apply (Let6989586621679736980Interleave'Sym4 xs0_a33a0 t_a33aL ts_a33aM is_a33aO) arg_a33he) arg_a33hf) arg_a33hg) (bound at Bug.hs:1166:29) lambda_a33ha :: Sing t_a33aL -> Sing ts_a33aM -> Sing is_a33aO -> Sing (Apply (Apply (Let6989586621679736931PermsSym1 xs0_a33a0) arg_a33h0) arg_a33h1) (bound at Bug.hs:1153:23) sTs :: Sing n_a1kQd (bound at Bug.hs:1143:34) sT :: Sing n_a1kQc (bound at Bug.hs:1143:31) lambda_a33gY :: Sing xs0_a33a0 -> Sing (Apply PermutationsSym0 t_a33gX) (bound at Bug.hs:1127:11) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 1328 | sInterleave')) | ^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 25 Apr '17

25 Apr '17

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't be fixed for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 25 Apr '17

25 Apr '17

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: At this point it seems unlikely that the remaining robustification will happen for 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13513: Incorrect behavior on arm64 with optimisations
by GHC 25 Apr '17

25 Apr '17

#13513: Incorrect behavior on arm64 with optimisations -------------------------------------+------------------------------------- Reporter: achirkin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Incorrect result | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I compiled ghc manually on a chromebook running ubuntu on aarch64 (arm64). I used `perf-llvm` build during compilation. This might be related to [https://ghc.haskell.org/trac/ghc/ticket/11578] but I am not sure how. While working with stack and cabal I experienced unusually long compilation times or seemingly random build failures from time to time. Luckily, at some point I got very interesting error in package `text`: {{{#!hs Prelude> import qualified Data.Text as T Prelude T> T.splitOn (T.pack " ") (T.pack "Hello world!") ["Hello","world!\54497\44724?\NUL\54521\44724?\NUL\NUL\NUL\NUL\NUL\34560...BIG BLOB OF BYTES HERE...\NUL"] }}} By default this package compiles with `-O2`, so I tried various options to determine when the result is correct and when is not. To test this I used bare GHC installation and `cabal-install-1.24.0.2`, (`cabal sandbox init && cabal install text --ghc-options="..."`). Here is what I tried so far: * BAD: `-O2` * BAD: `-O2 -fllvm -optlc-O3` * OK: `-O1 -fllvm -optlc-O3` * OK: `-O1 -fllvm -fliberate-case -fregs-graph -fspec-constr -optlc-O3` That is: when `text` package is compiled with `-O2` the result of `Text.splitOn` function is garbaged with random data; when it is compiled with `-O1`, the result is correct. Since `text` is represented using `ByteArray#` internally, I would suggest something is wrong with `ByteArray#`'s length attribute, but I am not sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

☑it's never too late
by matthew 25 Apr '17

25 Apr '17

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hey! It's never too late to read some interesting info here http://www.mrphuchoi.com/pool.php?4243 matthew [...] Content analysis details: (6.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL [14.186.146.6 listed in zen.spamhaus.org] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL 1.0 RCVD_IN_CSS RBL: Received via a relay in Spamhaus CSS 0.0 SPF_FAIL SPF: sender does not match SPF record (fail) [SPF failed: Please see http://www.openspf.net/Why?s=mfrom;id=matthew%40wellquite.org;ip=14.186.146…] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4967] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

[GHC] #13612: ghc.exe: panic! (the 'impossible' happened)
by GHC 24 Apr '17

24 Apr '17

#13612: ghc.exe: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hmemcpy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Full output: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): initTc: unsolved constraints WC {wc_insol = [W] n_a1qA :: t_a1qz[tau:1] (CHoleCan: n)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This failed on a trivial (albeit incorrect) "Hello world" code, while trying to execute it with stack: **stack Main.hs** The code file is attached. Note that this error happens when it incorrectly specifies the non- existing value **n** (instead of **name**) in the last expression. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8996: mark more things as const in C codegen
by GHC 24 Apr '17

24 Apr '17

#8996: mark more things as const in C codegen -------------------------------------------+------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Recently i've tried to build ghc-7.8.2 on ia64 and it overflows so called "short data" section. (it's where global 'static' variables live). I've looked at low-hanging fruits of squashing such global "variables". One source of them seems to be a string literal. Consider one-line module: {{{ module B (v) where v = "hello" }}} in '''-fvia-C''' (or unreg) mode it generates code like {{{ static char gibberish_str[] = "hello"; }}} It uselessly eats data section. The patch switches generator to emit: {{{ static const char gibberish_str[] = "hello"; }}} Some notes: 1. as far as I see native codegens already put ot to .rodata, thus it should be safe. 2. I likely didn't cover more cases, like - RelocatableReadOnlyData - and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))''' Size of unreg-stage2 on amd64 before and after the patch: {{{ $ size inplace/lib/bin/ghc-stage2 (unpatched) text data bss dec hex filename 81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2 $ size inplace/lib/bin/ghc-stage2 (patched) text data bss dec hex filename 83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2 }}} Text section increased for 1.6MBs (consts moved here, likely .rodata actually), data section decreased for 1.7MBs. I think with minor fiddling with linker flags we can merge equal constants later on. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13404: Derive instances for classes with associated types
by GHC 24 Apr '17

24 Apr '17

#13404: Derive instances for classes with associated types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- When trying to derive an instance of a class with associated types {{{#!hs import Data.Distributive import Data.Functor.Rep data Pair a = a :# a deriving Functor instance Distributive Pair where distribute :: Functor f => f (Pair a) -> Pair (f a) distribute = distributeRep instance Representable Pair where type Rep Pair = Bool index :: Pair a -> (Bool -> a) index (a :# _) False = a index (_ :# b) True = b newtype PAIR a = PAIR (Pair a) deriving (Functor, Representable) instance Distributive PAIR where distribute = {- distributeRep -} }}} {{{ • Can't make a derived instance of ‘Representable PAIR’ (even with cunning GeneralizedNewtypeDeriving): the class has associated types • In the newtype declaration for ‘PAIR’ }}} But it could create an instance {{{#!hs instance Representable PAIR where type Rep PAIR = Bool index :: forall a. PAIR a -> (Bool -> a) index = coerce (index :: Pair a -> (Bool -> a)) }}} Same with complicated expressions like {{{#!hs infixr 9 · type (·) = Compose newtype P f g h a = P (Product (f·g·f) (h·f·g) a) deriving (Functor, Foldable, Traversable, Applicative, Alternative, Distributive) instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Distributive (P f g h) where distribute = distributeRep instance (Functor f, Functor g, Functor h, Representable f, Representable g, Representable h) => Representable (P f g h) where type Rep (P f g h) = Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) index :: (P f g h) a -> (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) index = coerce (index @(Product (f·g·f) (h·f·g))) tabulate :: (Either (Rep f, (Rep g, Rep f)) (Rep h, (Rep f, Rep g)) -> a) -> (P f g h) a tabulate = coerce (tabulate @(Product (f·g·f) (h·f·g))) }}} Is this too limited to work on general -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11714: Kind of (->) type constructor is overly constrained
by GHC 24 Apr '17

24 Apr '17

#11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Currently the `(->)` type constructor has kind `* -> * -> *` (with some magic to make infix work for unlifted types. To quote the comment attached to `TysPrim.funTyCon`, > You might think that `(->)` should have type `?? -> ? -> *`, and you'd be right. But if we do that we get kind errors when saying > {{{ > instance Control.Arrow (->) > }}} > because the expected kind is `* -> * -> *`. The trouble is that the expected/actual stuff in the unifier does not go contra-variant, whereas the kind sub-typing does. Sigh. It really only matters if you use `(->)` in a prefix way, thus: `(->) Int# Int#`. And this is unusual. because they are never in scope in the source }}} This seems to imply that the restrictive kind arose out of the old subkinding story. Now that we have a more principled way of dealing with non-lifted kinds it seems we allow prefix uses to be as polymorphic as infix uses. Something like, {{{#!hs (->) :: forall (rep1 :: RuntimeRep) (rep2 :: RuntimeRep). TYPE rep1 -> TYPE rep2 -> * }}} Not only would this be a win for consistency, but it may also address some of the Core Lint issues that I'm seeing in #11011. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13316: Bad inlining cascade leads to slow optimisation
by GHC 24 Apr '17

24 Apr '17

#13316: Bad inlining cascade leads to slow optimisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Consider this simple program {{{ {-# INLINE [0] f #-} f x y = case y of True -> reverse x False -> reverse (reverse x) foo a b = let x = [a,a,a,a] in f x b }}} If you compile with -DDEBUG you'll see {{{ bash$ ghc-stage1 Foo.hs -O -fforce-recomp -c WARNING: file compiler/simplCore/SimplCore.hs, line 670 Simplifier bailing out after 4 iterations [17, 1, 1, 1] Size = {terms: 60, types: 49, coercions: 0, joins: 0/0}}}} }}} Yikes! One transformation per simplifier iteration! What is going on? Before inlining `f` we have {{{ (f [a,a,a,a] b) }}} Then, we inline, beta-reduce, and build let bindings thus {{{ let x1 = a : [] x2 = a : x1 x3 = a : x2 x4 = a : x3 in case b of True -> reverse x4 False -> reverse (reverse x4) }}} So far so good. But then, bizarrely, we do `postInlineUnconditionally` on `x4` (see comments in that function). But not on `x3` because its occ- info is "once inside lambda". Then in the next iteration we `postInlineUnconditionally` `x3`, and so on. Terrible, terrible. My thought: revisit these comments in `postInlineUnconditionally`: {{{ OneOcc { occ_in_lam = in_lam, occ_int_cxt = int_cxt } -- OneOcc => no code-duplication issue -> smallEnoughToInline dflags unfolding -- Small enough to dup -- ToDo: consider discount on smallEnoughToInline if int_cxt is true -- -- NB: Do NOT inline arbitrarily big things, even if one_br is True -- Reason: doing so risks exponential behaviour. We simplify a big -- expression, inline it, and simplify it again. But if the -- very same thing happens in the big expression, we get -- exponential cost! -- PRINCIPLE: when we've already simplified an expression once, -- make sure that we only inline it if it's reasonably small. && (not in_lam || -- Outside a lambda, we want to be reasonably aggressive -- about inlining into multiple branches of case -- e.g. let x = <non-value> -- in case y of { C1 -> ..x..; C2 -> ..x..; C3 -> ... } -- Inlining can be a big win if C3 is the hot- spot, even if -- the uses in C1, C2 are not 'interesting' -- An example that gets worse if you add int_cxt here is 'clausify' }}} What is particularly annoying in this case is that `x` is used in all code paths, so all this inlining simply duplicates code while gaining nothing. Moreover, if we had {{{ let x = blah in case y of A -> ...x... B -> ..x..x... C -> }}} then the multiple uses of `x` in the `B` branch would disable this entire `preInlineUnconditionally` thing, even though it might be a good idea to push the allocation of `x` into the `A` and `B` branches, to avoid the `C` code path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13316> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4