- ghc-tickets - Haskell.org

[GHC] #16038: Simplifier incorrectly breaks recursive groups
by GHC 25 Dec '18

25 Dec '18

#16038: Simplifier incorrectly breaks recursive groups -------------------------------------+------------------------------------- Reporter: osa1 | 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: -------------------------------------+------------------------------------- I found this while looking at compile time panic in my code for #9718. The test that triggers the panic is `T4003`, but here's a simpler version of the test: {{{ -- T4003B.hs module T4003B where import {-# SOURCE #-} T4003A (HsExpr) data HsOverLit id = OverLit (HsExpr id) deriving Eq ----------------------------------- -- T4003A.hs-boot module T4003A where data HsExpr i instance Eq i => Eq (HsExpr i) ----------------------------------- -- T4003A.hs module T4003A where import T4003B data HsExpr id = HsOverLit (HsOverLit id) | HsBracketOut (HsExpr id) deriving Eq }}} Compile in this order: T4003A.hs-boot, T4003B.hs, T4003A.hs {{{ $ ghc-stage1 -O -c T4003A.hs-boot $ ghc-stage1 -O -c T4003B.hs $ ghc-stage1 -O -c T4003A.hs }}} The last step fails with a panic because in the new STG pass I implemented for #9718 I assume that all recursive groups are already in a `Rec`, but this program has a set of bindings that are actually recursive but not in a `Rec`. If I dump ds and simpl outputs of the last step I see that this recursive group: (in the ds output) {{{ Rec { -- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0} $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V) -- RHS size: {terms: 9, types: 11, coercions: 0, joins: 0/0} $c/=_a287 $c/=_a287 = \ @ id_a27U $dEq_a27V eta_B2 eta_B1 -> $dm/= ($fEqHsExpr $dEq_a27V) eta_B2 eta_B1 -- RHS size: {terms: 37, types: 37, coercions: 0, joins: 1/3} $c==_a27X $c==_a27X = \ @ id_a27U $dEq_a27V -> let { $dEq_a283 $dEq_a283 = $fEqHsExpr $dEq_a27V } in let { $dEq_a281 $dEq_a281 = $fEqHsOverLit $dEq_a27V } in \ ds_d2jB ds_d2jC -> join { fail_d2jD fail_d2jD _ = False } in case ds_d2jB of { HsOverLit a1_a27Q -> case ds_d2jC of { __DEFAULT -> jump fail_d2jD void#; HsOverLit b1_a27R -> == $dEq_a281 a1_a27Q b1_a27R }; HsBracketOut a1_a27S -> case ds_d2jC of { __DEFAULT -> jump fail_d2jD void#; HsBracketOut b1_a27T -> == $dEq_a283 a1_a27S b1_a27T } } end Rec } -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Becomes non-recursive in simplifier output: {{{ Rec { -- RHS size: {terms: 34, types: 45, coercions: 0, joins: 0/0} $fEqHsExpr_$c== $fEqHsExpr_$c== = \ @ id_a27U $dEq_a27V ds_d2jB ds1_d2jC -> case ds_d2jB of { HsOverLit a1_a27Q -> case ds1_d2jC of { HsOverLit b1_a27R -> case a1_a27Q of { OverLit a2_a2k8 -> case b1_a27R of { OverLit b2_a2kc -> == (noinline $fxEqHsExpr $dEq_a27V) a2_a2k8 b2_a2kc } }; HsBracketOut ipv_s2kg -> False }; HsBracketOut a1_a27S -> case ds1_d2jC of { HsOverLit ipv_s2kj -> False; HsBracketOut b1_a27T -> $fEqHsExpr_$c== $dEq_a27V a1_a27S b1_a27T } } end Rec } -- RHS size: {terms: 13, types: 10, coercions: 0, joins: 0/0} $fEqHsExpr_$c/= $fEqHsExpr_$c/= = \ @ id_a27U $dEq_a27V eta_B2 eta1_B1 -> case $fEqHsExpr_$c== $dEq_a27V eta_B2 eta1_B1 of { False -> True; True -> False } -- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0} $fEqHsExpr $fEqHsExpr = \ @ id_a27U $dEq_a27V -> C:Eq ($fEqHsExpr_$c== $dEq_a27V) ($fEqHsExpr_$c/= $dEq_a27V) -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $fxEqHsExpr $fxEqHsExpr = $fEqHsExpr }}} Notice that `c==` refers to `fxEqHsExpr`, which refers to `fEqHsExpr`, which refers to `c==`, forming a recursive group. (Confirmed with GHC 8.6.3 and GHC HEAD) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc)
by GHC 24 Dec '18

24 Dec '18

#11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: perf/space_leaks/space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `WAY=profasm` is omitted by default for this test, but the code looks like this: Test.hs: {{{ import Data.List main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer) }}} {{{ $ ghc Test.hs -prof -O $ ./Test +RTS -hc Segmentation fault (core dumped) }}} Reproducible with at least 7.10.3 and HEAD, also without `-O`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14758: Retainer profiler can overflow the C stack
by GHC 24 Dec '18

24 Dec '18

#14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 8.4.1-alpha1 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'm not entirely sure what conditions trigger this, but I am observing a reliable segmentation fault with a program with large heap compiled with 8.4.1-alpha3 and run with retainer profiling enabled. Judging by the fact that the crashing instruction is a `mov _, ($rsp)`, I'm reasonable certain that the issue is a C stack overflow. The top of the stack looks like, {{{ #0 0x000000000249212c in retainClosure (c0=0x42af3459b8, cp0=cp0@entry=0x42af347000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1488 #1 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347000, bitmap=<optimized out>, size=<optimized out>, p=0x42af347260) at rts/RetainerProfile.c:1209 #2 retainStack (c=c@entry=0x42af347000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347370) at rts/RetainerProfile.c:1350 #3 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #4 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3473e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #5 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3473e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347690) at rts/RetainerProfile.c:1209 #6 retainStack (c=c@entry=0x42af3473e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347750) at rts/RetainerProfile.c:1350 #7 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af345d88, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #8 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3477c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #9 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3477c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347a70) at rts/RetainerProfile.c:1209 #10 retainStack (c=c@entry=0x42af3477c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347b30) at rts/RetainerProfile.c:1350 #11 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3481a8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #12 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af347ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #13 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347ba0, bitmap=<optimized out>, size=<optimized out>, p=0x42af347e50) at rts/RetainerProfile.c:1209 #14 retainStack (c=c@entry=0x42af347ba0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af347f10) at rts/RetainerProfile.c:1350 #15 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348408, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #16 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349000, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #17 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af349000, bitmap=<optimized out>, size=<optimized out>, p=0x42af3492b0) at rts/RetainerProfile.c:1209 #18 retainStack (c=c@entry=0x42af349000, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349370) at rts/RetainerProfile.c:1350 #19 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348668, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #20 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3493e0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #21 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3493e0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349690) at rts/RetainerProfile.c:1209 #22 retainStack (c=c@entry=0x42af3493e0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349750) at rts/RetainerProfile.c:1350 #23 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3488c8, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #24 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af3497c0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #25 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3497c0, bitmap=<optimized out>, size=<optimized out>, p=0x42af349a70) at rts/RetainerProfile.c:1209 #26 retainStack (c=c@entry=0x42af3497c0, c_child_r=c_child_r@entry=0x42bc4fd1a0, stackStart=<optimized out>, stackEnd=0x42af349b30) at rts/RetainerProfile.c:1350 #27 0x0000000002492870 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af348b28, r0=r0@entry=0x2a5ac20 <CCS_SYSTEM>) at rts/RetainerProfile.c:1686 #28 0x0000000002492887 in retainClosure (c0=<optimized out>, cp0=cp0@entry=0x42af349ba0, r0=r0@entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 ... }}} and this goes on for at least 30000 frames. It looks very much like this is a bug in the retainer profiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9627: Type error with functional dependencies
by GHC 24 Dec '18

24 Dec '18

#9627: Type error with functional dependencies -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached file should compile. The types T1, T2, and T3 are all equivalent types (T1 and T2 normalize to T3), but with foo::T1 and bar::T2 there is a type error. Rewriting the example using type families instead of FD makes it work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13322: Pattern synonyms in hs-boot files
by GHC 24 Dec '18

24 Dec '18

#13322: Pattern synonyms in hs-boot files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Pattern synonyms are not permitted in hs-boot files: {{{ ezyang@sabre:~/bun$ ghc-head -c A.hs-boot A.hs-boot:3:5: error: Misplaced pattern synonym signature: pattern X :: Bool | 3 | pattern X :: Bool | ^^^^^^^^^^^^^^^^^ A.hs-boot:3:13: error: The pattern synonym signature for ‘X’ lacks an accompanying binding | 3 | pattern X :: Bool | }}} There isn't really any reason why they shouldn't be supported. One thing to check closely: if we bundle a pattern synonym declared in an hs-boot file with another type, in an hs-boot file, what happens? In particular, does an hs file which doesn't bundle the pattern synonym and the type valid? If we add support for them, make sure that Backpack signatures handle it properly. In particular, suppose we have: {{{ signature A(T(X)) where data T pattern X :: T }}} Then, when we instantiate A, we must be careful to NOT blindly reuse the implementing module of T for X (as we do today in `uAvailInfo` in `NameShape`), since T and X may be defined in different modules. I'm not likely to implement this unless someone asks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13322> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16070: Better inferred signatures
by GHC 24 Dec '18

24 Dec '18

#16070: Better inferred signatures -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Consider this (taken from [https://github.com/ghc-proposals/ghc- proposals/pull/158#issuecomment-448549030 here]) {{{ class FieldType x r ~ a => HasField (x :: k) r a where type FieldType x r getField :: r -> a setField :: r -> a -> r f r = setField @"bar" r (getField @"foo" r) }}} We get this type inferred for `f`: {{{ f :: forall r. (HasField "bar" r (FieldType "bar" r), HasField "foo" r (FieldType "bar" r)) => r -> r }}} But actually this signature is equivalent {{{ f :: forall r a. (HasField "bar" r a, HasField "foo" r a) => r -> r }}} and it's quite a bit shorter. Similarly, from this definition {{{ g r = setField r }}} We get this inferred type {{{ g :: forall r p. HasField "bar" r (FieldType "bar" r) => p -> r -> FieldType "bar" r -> r }}} where again we might prefer {{{ g :: forall r a. HasField "bar" r a => r -> a -> r }}} '''Question''': could we make GHC infer the briefer types? After all, it does some similar abbreviation with type classes. Where we could infer `(Ord a, Eq a)` we collapse out the `Eq a` and just infer the context `(Ord a)`. There is nothing record-specific about this ticket. It's just about using inferred equality constraints to simplify the inferred signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16070> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15298: Support spliced function names in type signatures in TH declaration quotes
by GHC 24 Dec '18

24 Dec '18

#15298: Support spliced function names in type signatures in TH declaration quotes -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11129 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There doesn't seem to be a way to splice function names into type signatures in Template Haskell declaration quotes `[d|...|]`. For example, `fDecl1` below does not work. According to [https://stackoverflow.com/a/32279198/470844 this StackOverflow answer], the approach in `fDecl2` below used to work, but it doesn't work with recent GHCs and is much less readable than `fDecl1`. {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH fName :: Name fName = mkName "f" fTy :: TypeQ fTy = [t| Int |] fBody :: ExpQ fBody = [e| 3 |] -- | Not allowed: -- -- @ -- error: -- Invalid type signature: $fName :: ... -- Should be of form <variable> :: <type> -- @ -- -- Similarly, using @$(varP fName) :: $fTy@ fails with an analogous -- error. fDecl1 :: DecsQ fDecl1 = [d| $fName :: $fTy $(varP fName) = $fBody |] -- | Not allowed: -- -- @ -- error: -- Splices within declaration brackets not (yet) handled by Template Haskell -- @ fDecl2 :: DecsQ fDecl2 = [d| $((:[]) <$> sigD fName fTy) $(varP fName) = $fBody |] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15298> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3379: GHC should use the standard binary package
by GHC 23 Dec '18

23 Dec '18

#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Hey, Ben, I missed the second part of your last post, unfortunately (read the email notification where it only shows the first version). I think there is an interesting design task here. You see, `Data.Binary` deals solely with serialization while GHC's Binary has serialization to the particular type of storage (`BinHandle` structure). As the first step, I think, we could factorize `GHC.Binary` to just use `Data.Binary` instead of trying to completely remove the former at once. For that, something like {{{#!haskell instance Data.Binary a => GHC.Binary a where ... }}} could work? My impression is that most of the instances of `GHC.Binary` are really boring, and all clever business is done directly with `BinHandle`s inside `Iface`-related modules. Discalaimer: I'm not totally sure what this `BinHandle`-related business is about. I read some Notes in the sources but didn't get much. The `IORef BinArray` part makes sense, but the rest… For now, I'm stuck with the error I listed above. Strangely enough, when doing `make test` on my brunch with `Data.Binary`-derived instance of `GHC.Binary ArgFlag`, I randomly get either that one error I mentioned above, or 518 errors (including the one above), all are with "bad stderr" or "bad stdout". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16090: Typeset Big-O complexities with TeX-style notation in libraries/base
by GHC 23 Dec '18

23 Dec '18

#16090: Typeset Big-O complexities with TeX-style notation in libraries/base -------------------------------------+------------------------------------- Reporter: supersven | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.6.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: -------------------------------------+------------------------------------- In the code review of #15003, @hvr proposed to typeset Big-Os in TeX-style instead of using italic (1). This will lead to a more idiomatic typesetting. See 2 for an example. **Task:** Replace all italic Big-Os in libraries/base with TeX-style notation. 1. - https://github.com/ghc/ghc/pull/239#discussion_r242167454 1. - https://hackage.haskell.org/package/text-containers-0.1.0.0/docs /Data-TextSet-Unboxed.html#v:size -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code
by GHC 23 Dec '18

23 Dec '18

#16064: Improving Placement of Heap Checks - Avoiding Slowdowns in Hot Code -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: Keywords: CodeGen, | Operating System: Unknown/Multiple Performance | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #16040, #14791, | #8326, #12231, #1498 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When generating both heap and stack checks in Cmm, GHC can sometimes be fairly obtuse about their placement. As a result, they can be generated for paths in hot code that actually do not perform any allocation. Examples can be found in the related tickets, particularly #14791 and #16040. This ticket exists to track the work [https://ghc.haskell.org/trac/ghc/ticket/16040#comment:5 proposed] by Simon to detect such code patterns. They are described as follows: 1. A primitive case with no allocation upstream from it. 2. One alternative that performs no allocation. Under such circumstances the stack/heap checks can be moved from being performed on every iteration to being performed just prior to the allocation itself. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2