February 2019 - ghc-tickets

[GHC] #16168: Prelude docs for Integer mention J#
by GHC 18 Feb '19

18 Feb '19

#16168: Prelude docs for Integer mention J# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: newcomer | 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 was just looking through http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#t:Integer and noticed that it mentions `J#` and `I#`. This is certainly an implementation detail that should not be exposed to readers of the Prelude documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16338: Update CI images to 8.6.* and cabal-2.4.*
by GHC 18 Feb '19

18 Feb '19

#16338: Update CI images to 8.6.* and cabal-2.4.* -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- The docker images need updating to a more recent GHC release. Probably best to do this after 8.6.4 is released. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16338> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16337: Investigate using Gitlab "Review Apps" to review documentation
by GHC 18 Feb '19

18 Feb '19

#16337: Investigate using Gitlab "Review Apps" to review documentation -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- There are these things called "Review Apps" which are meant for reviewing things like websites/documentation. It might be good to set this up for reviewing documentation changes which can be hard to get right. https://docs.gitlab.com/ee/ci/review_apps/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16337> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16336: Build and deploy docker images on gitlab CI
by GHC 18 Feb '19

18 Feb '19

#16336: Build and deploy docker images on gitlab CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- The docker files we use for CI are in the `.circleci` folder at the moment. There should be a CI job which can be triggered to build and upload these images to docker hub. This would mean that anyone can update the builders rather than being block on one person. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16335: Make CPR Analysis more aggressive for inductive cases
by GHC 18 Feb '19

18 Feb '19

#16335: Make CPR Analysis more aggressive for inductive cases -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: CPRAnalysis | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While investigating the generated Core for a simple toy benchmark, I came up with the following minimal example: {{{#!hs data Expr = Lit Int | Plus Expr Expr eval :: Expr -> Int eval (Lit n) = n eval (Plus a b) = eval a + eval b }}} resulting in the following Core: {{{ eval = \ (ds_d112 :: Expr) -> case ds_d112 of { Lit n_aXf -> n_aXf; Plus a_aXg b_aXh -> case eval a_aXg of { GHC.Types.I# x_a1bK -> case eval b_aXh of { GHC.Types.I# y_a1bO -> GHC.Types.I# (GHC.Prim.+# x_a1bK y_a1bO) } } } }}} Note that this needlessly unboxes and boxes primitive Ints. Lifting this is precisely the job of CPR, but `eval` doesn't exactly have the CPR property: the `Lit` case doesn't return a product. But we're punishing ourselves for the base case when ''even the function itself'' recurses multiple times! The code resulting from WWing here wouldn't even look bad in the `Lit` case: {{{ Foo.$weval = \ (w_s1cn :: Expr) -> case w_s1cn of { Lit dt_d11b -> case dt_d11b { I# ds_abcd -> ds_abcd }; Plus a_aXf b_aXg -> case Foo.$weval a_aXf of ww_s1cq { __DEFAULT -> case Foo.$weval b_aXg of ww1_X1dh { __DEFAULT -> GHC.Prim.+# ww_s1cq ww1_X1dh } } } eval = \ (w_s1cn :: Expr) -> case Foo.$weval w_s1cn of ww_s1cq { __DEFAULT -> GHC.Types.I# ww_s1cq } }}} Granted, this is bad for the case where there is no recursion happening and we need the result of `eval` boxed, but that's a small price to pay IMO. I begin to think of CPR more of as the "dual" to SpecConstr than to Strictness Analysis. Return pattern specialisation, so to speak. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules
by GHC 18 Feb '19

18 Feb '19

#13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ghci (in the default config) wants to show me all the modules that are currently loaded. If I have a great many of these (think: hundreds) then this is impractical, because I have to scroll back to see what actually interests me (output of last command). I can change the prompt (`:set prompt "> "`), but I don't see how to switch off the display of all module names in `:r` command. I have to scroll back (several screenfulls) to even find out whether the reload was successful, since the status (OK/Failed) is at the very beginning - and the reason for the Failure is before that. Cf. https://mail.haskell.org/pipermail/haskell-cafe/2017-May/126983.html (but there was no reaction) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13706> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2]
by GHC 18 Feb '19

18 Feb '19

#14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies, | PartialTypeSignatures | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #13877 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally spun off from #13877.) The following program gives a somewhat decent error message in GHC 8.0.1: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data family Sing (a :: k) data WeirdList :: Type -> Type where WeirdNil :: WeirdList a WeirdCons :: a -> WeirdList (WeirdList a) -> WeirdList a data instance Sing (z :: WeirdList a) where SWeirdNil :: Sing WeirdNil SWeirdCons :: Sing w -> Sing wws -> Sing (WeirdCons w wws) elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl elimWeirdList SWeirdNil pWeirdNil _ = pWeirdNil elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) }}} {{{ $ /opt/ghc/8.0.1/bin/ghci Foo.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:34:8: error: • Cannot apply expression of type ‘Sing wl -> (forall y. p x0 t3 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p (WeirdList z) t2 xs -> p z t1 ('WeirdCons x xs)) -> p a t0 wl’ to a visible type argument ‘WeirdList z’ • In the sixth argument of ‘pWeirdCons’, namely ‘(elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons)’ In the expression: pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) In an equation for ‘elimWeirdList’: elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) }}} But in GHC 8.0.2, 8.2.1, and HEAD, it panics to varying degrees: {{{ $ /opt/ghc/8.0.2/bin/ghci Foo.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘t0’ Where: ‘t0’ is an ambiguous type variable ‘x0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl • Relevant bindings include elimWeirdList :: Sing wl -> (forall y. p x0 t0 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p (WeirdList z) t1 xs -> p z t2 ('WeirdCons x xs)) -> p a t3 wl (bound at Foo.hs:29:1) Foo.hs:26:44: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: z_a13X[sk] }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Foo.hs, interpreted ) Foo.hs:21:18: error: • The kind of variable ‘wl1’, namely ‘WeirdList a1’, depends on variable ‘a1’ from an inner scope Perhaps bind ‘wl1’ sometime after binding ‘a1’ • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 21 | elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Foo.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘w0’ Where: ‘w0’ is an ambiguous type variable ‘x0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 24 | -> (forall (y :: Type). p _ WeirdNil) | ^ Foo.hs:26:44: error:ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): No skolem info: z_a1sY[sk:2] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2653:5 in ghc:TcErrors }}} (The error messages from HEAD, at commit 791947db6db32ef7d4772a821a0823e558e3c05b, are the same as in GHC 8.2.1.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14040> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case)
by GHC 18 Feb '19

18 Feb '19

#16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a seemingly innocuous program, minimized from the `kan-extensions` library: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where newtype Curried g h a = Curried { runCurried :: forall r. g (a -> r) -> h r } instance Functor g => Functor (Curried g h) where fmap f (Curried g) = Curried (g . fmap (.f)) instance (Functor g, g ~ h) => Applicative (Curried g h) where pure a = Curried (fmap ($a)) Curried mf <*> Curried ma = Curried (ma . mf . fmap (.)) {-# INLINE (<*>) #-} -- The Core Lint error goes away if you remove this INLINE pragma }}} However, it triggers a Core Lint error on GHC 8.2.2 through HEAD if you compile it with `-O` and `-dcore-lint`: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -dcore-lint Bug.hs -O [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** <no location info>: warning: In the expression: (case heq_sel @ (* -> *) @ (* -> *) @ h_a1eC @ h_a1eC ($d~_a1eE `cast` (((~) <* -> *>_N co_a1hx <h_a1eC>_N)_R ; N:~[0] <* -> *>_N <h_a1eC>_N <h_a1eC>_N :: (g_a1eB ~ h_a1eC) ~R# (h_a1eC ~~ h_a1eC))) of co_X1ij { __DEFAULT -> (\ (@ a_a1fg) (@ b_a1fh) (ds_d1yw :: Curried h_a1eC h_a1eC (a_a1fg -> b_a1fh)) (ds_d1yx :: Curried h_a1eC h_a1eC a_a1fg) (@ r_a1fn) -> let { g_X1zi :: h_a1eC (b_a1fh -> r_a1fn) -> h_a1eC ((a_a1fg -> b_a1fh) -> a_a1fg -> r_a1fn) [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] g_X1zi = fmap @ h_a1eC ($dFunctor_a1eD `cast` ((Functor co_a1hx)_R :: Functor g_a1eB ~R# Functor h_a1eC)) @ (b_a1fh -> r_a1fn) @ ((a_a1fg -> b_a1fh) -> a_a1fg -> r_a1fn) (. @ b_a1fh @ r_a1fn @ a_a1fg) } in \ (x_X1zn :: h_a1eC (b_a1fh -> r_a1fn)) -> (ds_d1yx `cast` (N:Curried[0] <h_a1eC>_R <h_a1eC>_R <a_a1fg>_N :: Curried h_a1eC h_a1eC a_a1fg ~R# (forall r. h_a1eC (a_a1fg -> r) -> h_a1eC r))) @ r_a1fn ((ds_d1yw `cast` (N:Curried[0] <h_a1eC>_R <h_a1eC>_R <a_a1fg -> b_a1fh>_N :: Curried h_a1eC h_a1eC (a_a1fg -> b_a1fh) ~R# (forall r. h_a1eC ((a_a1fg -> b_a1fh) -> r) -> h_a1eC r))) @ (a_a1fg -> r_a1fn) (g_X1zi x_X1zn))) `cast` (forall (a :: <*>_N) (b :: <*>_N). <Curried h_a1eC h_a1eC (a -> b)>_R ->_R <Curried h_a1eC h_a1eC a>_R ->_R Sym (N:Curried[0] <h_a1eC>_R <h_a1eC>_R <b>_N) :: (forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> forall r. h_a1eC (b -> r) -> h_a1eC r) ~R# (forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> Curried h_a1eC h_a1eC b)) }) @ b_a1gi @ b_a1gi ((<$ @ (Curried g_a1eB h_a1eC) ($dFunctor_s1zH `cast` ((Functor (Curried (Sym co_a1hx) <h_a1eC>_N)_N)_R :: Functor (Curried h_a1eC h_a1eC) ~R# Functor (Curried g_a1eB h_a1eC))) @ (b_a1gi -> b_a1gi) @ a_a1gh (breakpoint @ b_a1gi) a1_a1z1) `cast` (Sym (Curried (Sub (Sym co_a1hx)) <h_a1eC>_R <b_a1gi -> b_a1gi>_N)_R :: Curried g_a1eB h_a1eC (b_a1gi -> b_a1gi) ~R# Curried h_a1eC h_a1eC (b_a1gi -> b_a1gi))) (a2_a1z2 `cast` (Sym (Curried (Sub (Sym co_a1hx)) <h_a1eC>_R <b_a1gi>_N)_R :: Curried g_a1eB h_a1eC b_a1gi ~R# Curried h_a1eC h_a1eC b_a1gi)) Type of case alternatives not the same as the annotation on case: Actual type: forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> Curried h_a1eC h_a1eC b Annotation on case: forall a b. Curried g_a1eB h_a1eC (a -> b) -> Curried g_a1eB h_a1eC a -> Curried g_a1eB h_a1eC b }}} The size of the `-dcore-lint` output is enormous, so I'll post it separately as an attachment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16243: Improve fregs-graph.
by GHC 18 Feb '19

18 Feb '19

#16243: Improve fregs-graph. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: fregs-graph | 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'm creating this as a way to keep track of shortcomings of the current implementation. Some of these are directly taken from TODOS, other are my own opinions. = Things that could be looked at. == Compress spill slots. Currently we assign each vreg a fixed spill slot. This is terrible for cache performance. It's possible to end up with sequences like this: {{{#!asm block_ca01_info: _ca01: movq 16(%rbp),%r14 movq 24(%rbp),%rax movq %rax,144(%rsp) movq 32(%rbp),%rsi movq 40(%rbp),%rdi movq 64(%rbp),%rbx movq 56(%rbp),%rax movq %rax,208(%rsp) movq 48(%rbp),%rax movq %rax,168(%rsp) movq 8(%rbp),%rax movq %rax,216(%rsp) addq $8,%rbp }}} Which splits spill slots over multiple cache lines increasing cache pressure. Things possibly worth trying: * Assign spill slots in the order they appear - hopefully reducing the average spread within code blocks. * Dynamically assign vregs to spill slots. For the later if we have large independent subgraphs we will sometimes get away with using far fewer slots. The reason simply being that non overlapping vregs can share spill slots. Doing this in an efficient manner however isn't easy. == We sometimes load + spill vregs when we could use memory addressing. One example I've seen a few times in nofib is this: {{{ movq 208(%rsp),%rax incq %rax movq %rax,208(%rsp) }}} Which we should replace with a single `inc` operating on memory. == Lift the stack size limit. There is already a patch [https://gitlab.haskell.org/ghc/ghc/merge_requests/219 in flight]. == Revisit spill costs. Currently the allocator always spills the longest live range. Which often works but is certainly not a great metric. Ideas: === Consider loop membership. At least for x86/64 this would be easy to achieve on basic block granularity using the CFG that is also used for block layout. === Revisit chaitins cost model. There have been major changes to cpus (amd64 becoming the norm) and the backend so at a minimum this cost model should be reevaluated. == Try splitting long live ranges instead of simply spilling the complete live range. After all long live ranges were the original reason to switch to a life range only based cost heuristic. == Use a different spill algorithm altogether. Maybe Chows live range splitting based approach would be an option. See "The priority based coloring approach to register allocation" for details. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16333: Implement Loop-invariant code motion / Hoisting for Cmm
by GHC 18 Feb '19

18 Feb '19

#16333: Implement Loop-invariant code motion / Hoisting for Cmm -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12808 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we don't but we should. An example from nofib: This is the innermost loop of fannkuch-redux. {{{ #!C ca12: _s9D0::I64 = %MO_UU_Conv_W8_W64(I8[_s9zN::I64]); if (_s9D0::I64 != 0) goto ca1f; else goto ca1i; ca1f: I64[Sp - 16] = ca1d; R3 = _s9zN::I64 + _s9D0::I64; R2 = _s9zN::I64; I64[Sp - 8] = _s9CV::I64; I64[Sp] = _s9Cd::I64; I64[Sp + 40] = _s9Cc::I64; I64[Sp + 48] = _s9Cb::I64; I64[Sp + 56] = _s9zN::I64; Sp = Sp - 16; call $wflopp_r9x0_info(R3, R2) returns to ca1d, args: 8, res: 8, upd: 8; ca1d: Sp = Sp + 16; _s9CV::I64 = I64[Sp - 8] + 1; _s9Cd::I64 = I64[Sp + 0]; 16 _s9z5::I64 = I64[Sp + 8]; //24 _s9zv::I64 = I64[Sp + 16]; 32 _s9zx::I64 = I64[Sp + 24]; 40 _s9zz::I64 = I64[Sp + 32]; 48 _s9Cc::I64 = I64[Sp + 40]; 56 _s9Cb::I64 = I64[Sp + 48]; 64 _s9zN::I64 = I64[Sp + 56]; 72 goto ca12; }}} We should try to move the loads NOT used in the loop out of the loop at least. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1