- ghc-tickets - Haskell.org

[GHC] #16004: Vector performance regression in GHC 8.6
by GHC 04 Feb '19

04 Feb '19

#16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Hello. With the following code, I can observe a performance regression between ghc 8.4 and 8.6: {{{#!haskell {-# LANGUAGE ScopedTypeVariables #-} module Main where import qualified Data.Vector.Unboxed.Mutable as Vector import qualified Data.Vector.Unboxed as VectorU import Data.Foldable (for_) main :: IO () main = do let n = 1000 let vUnmutable :: VectorU.Vector Double = VectorU.generate (n * n) (\i -> fromIntegral i) v :: Vector.IOVector Double <- VectorU.unsafeThaw vUnmutable for_ [0..(n - 1)] $ \k -> do for_ [0..(n - 1)] $ \i -> do for_ [0..(n - 1)] $ \j -> do a <- Vector.unsafeRead v (i * n + k) b <- Vector.unsafeRead v (k * n + j) c <- Vector.unsafeRead v (i * n + j) Vector.unsafeWrite v (i * n + j) (min (a + b) c) }}} Built with `-O2` and with / without `-fllvm`. I'm using `vector-0.12.0.1`. Here are the timing results: GHC 8.2.2 no llvm: 1.7s llvm: 1.0s GHC 8.4.4 no llvm: 1.6s llvm: 0.9s GHC 8.6.2 no llvm: 4.8s llvm: 4.3s I'm using the following bash + nix script to gather theses timings: {{{#!bash nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc822.ghcWithPackages(p: [p.vector])' -p llvm_39 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc844.ghcWithPackages(p: [p.vector])' -p llvm_5 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce- recomp; time ./FloydBench" nix-shell -p 'haskell.packages.ghc862.ghcWithPackages(p: [p.vector])' -p llvm_6 --run "ghc-pkg list | grep vector; ghc -O2 FloydBench.hs -Wall -fforce-recomp -fllvm; time ./FloydBench" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16004> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #14180: Strange/bad error message binding unboxed type variable
by GHC 04 Feb '19

04 Feb '19

#14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.2 Component: Compiler | Version: 8.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# language TypeInType, TypeFamilies, MagicHash #-} import GHC.Exts type family MatchInt (f :: Int) :: () where MatchInt ('I# x) = '() }}} produces {{{ <interactive>:2:59: error: • Couldn't match a lifted type with an unlifted type When matching kinds k0 :: * Int# :: TYPE 'IntRep Expected kind ‘Int#’, but ‘x’ has kind ‘k0’ • In the first argument of ‘ 'I#’, namely ‘x’ In the first argument of ‘MatchInt’, namely ‘( 'I# x)’ In the type family declaration for ‘MatchInt’ }}} If, however, I replace `x` in the pattern with `_`, the type checker is satisfied. If I give it a pattern signature, {{{#!hs MatchInt ('I# (x :: Int#)) = '() }}} I get a different (and equally unhelpful) error message, {{{ • Expecting a lifted type, but ‘Int#’ is unlifted • In the kind ‘Int#’ In the first argument of ‘ 'I#’, namely ‘(x :: Int#)’ In the first argument of ‘MatchInt’, namely ‘( 'I# (x :: Int#))’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13624: loadObj() does not respect alignment
by GHC 04 Feb '19

04 Feb '19

#13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | 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: -------------------------------------+------------------------------------- This is perhaps known, but I'll write it down here in case somebody else runs into this problem as well. Since `loadObj()` just `mmap()`s the entire object file and decodes it ''in place'', it does not respect the alignment requirements specified in the section headers. This is problematic for instructions which require alignment, e.g. SSE, AVX. The attached `map.ll` program is `map (+1)` over an array of floating point numbers. In particular, the core loop is 8-way SIMD vectorised x 4-way unrolled, for 32-elements per loop iteration. A tail loop handles any remainder one-at-a-time. You can compile it using `llc -filetype=obj -mcpu=native map.ll`. For a CPU with AVX instructions (sandy bridge or later) you should get the following: {{{ $ objdump -d map.o Disassembly of section .text: 0000000000000000 <map>: 0: 49 89 f3 mov %rsi,%r11 3: 49 29 fb sub %rdi,%r11 6: 0f 8e f9 00 00 00 jle 105 <map+0x105> c: 49 83 fb 20 cmp $0x20,%r11 10: 0f 82 bd 00 00 00 jb d3 <map+0xd3> 16: 4d 89 da mov %r11,%r10 19: 49 83 e2 e0 and $0xffffffffffffffe0,%r10 1d: 4d 89 d9 mov %r11,%r9 20: 49 83 e1 e0 and $0xffffffffffffffe0,%r9 24: 0f 84 a9 00 00 00 je d3 <map+0xd3> 2a: 49 01 fa add %rdi,%r10 2d: 48 8d 44 ba 60 lea 0x60(%rdx,%rdi,4),%rax 32: 49 8d 7c b8 60 lea 0x60(%r8,%rdi,4),%rdi 37: c5 fc 28 05 00 00 00 vmovaps 0x0(%rip),%ymm0 # 3f <map+0x3f> 3e: 00 3f: 4c 89 c9 mov %r9,%rcx 42: 66 66 66 66 66 2e 0f data16 data16 data16 data16 nopw %cs:0x0(%rax,%rax,1) 49: 1f 84 00 00 00 00 00 50: c5 f8 10 4f a0 vmovups -0x60(%rdi),%xmm1 55: c5 f8 10 57 c0 vmovups -0x40(%rdi),%xmm2 5a: c5 f8 10 5f e0 vmovups -0x20(%rdi),%xmm3 5f: c5 f8 10 27 vmovups (%rdi),%xmm4 63: c4 e3 75 18 4f b0 01 vinsertf128 $0x1,-0x50(%rdi),%ymm1,%ymm1 6a: c4 e3 6d 18 57 d0 01 vinsertf128 $0x1,-0x30(%rdi),%ymm2,%ymm2 71: c4 e3 65 18 5f f0 01 vinsertf128 $0x1,-0x10(%rdi),%ymm3,%ymm3 78: c4 e3 5d 18 67 10 01 vinsertf128 $0x1,0x10(%rdi),%ymm4,%ymm4 7f: c5 f4 58 c8 vaddps %ymm0,%ymm1,%ymm1 83: c5 ec 58 d0 vaddps %ymm0,%ymm2,%ymm2 87: c5 e4 58 d8 vaddps %ymm0,%ymm3,%ymm3 8b: c5 dc 58 e0 vaddps %ymm0,%ymm4,%ymm4 8f: c4 e3 7d 19 48 b0 01 vextractf128 $0x1,%ymm1,-0x50(%rax) 96: c5 f8 11 48 a0 vmovups %xmm1,-0x60(%rax) 9b: c4 e3 7d 19 50 d0 01 vextractf128 $0x1,%ymm2,-0x30(%rax) a2: c5 f8 11 50 c0 vmovups %xmm2,-0x40(%rax) a7: c4 e3 7d 19 58 f0 01 vextractf128 $0x1,%ymm3,-0x10(%rax) ae: c5 f8 11 58 e0 vmovups %xmm3,-0x20(%rax) b3: c4 e3 7d 19 60 10 01 vextractf128 $0x1,%ymm4,0x10(%rax) ba: c5 f8 11 20 vmovups %xmm4,(%rax) be: 48 83 e8 80 sub $0xffffffffffffff80,%rax c2: 48 83 ef 80 sub $0xffffffffffffff80,%rdi c6: 48 83 c1 e0 add $0xffffffffffffffe0,%rcx ca: 75 84 jne 50 <map+0x50> cc: 4d 39 cb cmp %r9,%r11 cf: 75 05 jne d6 <map+0xd6> d1: eb 32 jmp 105 <map+0x105> d3: 49 89 fa mov %rdi,%r10 d6: 4c 29 d6 sub %r10,%rsi d9: 4a 8d 04 92 lea (%rdx,%r10,4),%rax dd: 4b 8d 0c 90 lea (%r8,%r10,4),%rcx e1: c5 fa 10 05 00 00 00 vmovss 0x0(%rip),%xmm0 # e9 <map+0xe9> e8: 00 e9: 0f 1f 80 00 00 00 00 nopl 0x0(%rax) f0: c5 fa 58 09 vaddss (%rcx),%xmm0,%xmm1 f4: c5 fa 11 08 vmovss %xmm1,(%rax) f8: 48 83 c0 04 add $0x4,%rax fc: 48 83 c1 04 add $0x4,%rcx 100: 48 ff ce dec %rsi 103: 75 eb jne f0 <map+0xf0> 105: c5 f8 77 vzeroupper 108: c3 req }}} The attached `test.c` will load the object file and try to execute it. The `#define N` on line 7 will change the size of the array. For fewer than 32 elements this works as expected (where the input array is [0..N-1]): {{{ $ ./build.sh + llc-4.0 -filetype=obj -mcpu=native map.ll + ghc --make -no-hs-main test.c $ ./a.out array size is 31 calling function... ok 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0 }}} For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. {{{ $ lldb a.out (lldb) target create "a.out" Current executable set to 'a.out' (x86_64). (lldb) run Process 7294 launched: '<snip>/a.out' (x86_64) array size is 32 calling function... Process 7294 stopped * thread #1: tid = 0xc41676, 0x000000010019f207, queue = 'com.apple.main- thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000000010019f207 -> 0x10019f207: vmovaps 0xe1(%rip), %ymm0 0x10019f20f: movq %r9, %rcx 0x10019f212: nopw %cs:(%rax,%rax) 0x10019f220: vmovups -0x60(%rdi), %xmm1 }}} The `VMOVAPS` instruction requires the source address to be 32-byte aligned. It is attempting to load 8 floats from one of the const sections (the ones for the +1), but since the section was not loaded at the required alignment, fails. I've tested this on x86_64 macOS (Mach-O) and ubuntu (ELF). I don't have any other systems to test on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #16284: Abortion of fixed-point iteration in Demand Analyser discards sound results
by GHC 04 Feb '19

04 Feb '19

#16284: Abortion of fixed-point iteration in Demand Analyser discards sound results -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple DemandAnalysis | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs -- Extracted from T4903 module Foo where data Tree = Bin Tree Tree tree :: Tree tree = Bin tree tree eq :: Tree -> Bool eq (Bin l r) = eq l && eq r }}} `eq` amounts to the following Core: {{{#!hs eq = \ (ds_d20O :: Tree) -> case ds_d20O of { Bin l_aY8 r_aY9 -> case eq l_aY8 of { False -> False; True -> eq r_aY9 } } }}} It clearly diverges. That's also what pure strictness/termination/CPR analysis would find out. But because usage analysis can't find out in finite time (and that's fine) that `eq` uses its argument completely, we abort fixed-point iteration [1] and return `nopSig`, discarding useful and sound strictness information we found out along the way, like the fact that it diverges. This isn't hard to fix: Just track which parts of the signature were still unsound during abortion and only zap them. I'm only recording this for posterity and as an argument in a discussion I'll maybe start in a few months of time... [1] This is the ascending chain of demands on `ds_d20O` during fixed-point iteration: {{{ H U(1*H,1*H) U(1*U(1*H,1*H),1*U(1*H,1*H)) ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction
by GHC 04 Feb '19

04 Feb '19

#10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compare {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 -XMonomorphismRestriction GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> let a = (+) Prelude> :t a a :: Num a => a -> a -> a }}} with {{{ rwbarton@morphism:/tmp$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XMonomorphismRestriction Prelude> let a = (+) Prelude> :t a a :: Integer -> Integer -> Integer }}} Confusing! This also occurred in 7.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10857> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #16278: Exhaustivity checking GADT with free variables
by GHC 04 Feb '19

04 Feb '19

#16278: Exhaustivity checking GADT with free variables -------------------------------------+------------------------------------- Reporter: andrewthad | 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 the following example: {{{#!hs {-# language DataKinds #-} {-# language TypeFamilies #-} {-# language GADTs #-} {-# language KindSignatures #-} {-# OPTIONS_GHC -Wall -fforce-recomp #-} module GadtException where import Data.Kind (Type) import GHC.Exts data Send = Send data SocketException :: Send -> Type where LocalShutdown :: SocketException 'Send OutOfMemory :: SocketException a someSocketException :: SocketException a someSocketException = OutOfMemory foo :: Int foo = case someSocketException :: SocketException Any of LocalShutdown -> 2 OutOfMemory -> 1 }}} In `foo`, GHC's exhaustivity checker requires a pattern match on `LocalShutdown`. However, `LocalShutdown` is not an inhabitant of `SocketException Any`. What I would really like is for this to go one step further. I shouldn't even need to write the type annotation. That is, with the above code otherwise unchanged, GHC should recognize that {{{#!hs foo :: Int foo = case someSocketException of OutOfMemory -> 1 }}} handles all possible cases. Since fully polymorphic type variables become `Any` at some point during typechecking, I would expect that if this worked with the `SocketException Any` type signature, it would work without it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16278> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15185: Enum instance for IntX / WordX are inefficient
by GHC 04 Feb '19

04 Feb '19

#15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 Libraries | 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 following factorial benchmark show high discrepancy in performance between `Int` and `Int64` (and similarly between `Word` and `Word64`) when using `product [1..n]` to compute factorial: {{{#!haskell {-# LANGUAGE TypeApplications #-} import Criterion.Main import Data.Int import Data.Word import Numeric.Natural fact :: Integral t => t -> t fact n = product [1..n] fact2 :: Integral t => t -> t fact2 n = go 1 n where go acc 1 = acc go acc n = go (acc * n) (n - 1) main :: IO () main = defaultMain [ bgroup "fact 20" [ bench "Int" $ whnf (fact @Int) 20 , bench "Word" $ whnf (fact @Word) 20 , bench "Int64" $ whnf (fact @Int64) 20 , bench "Word64" $ whnf (fact @Word64) 20 , bench "Integer" $ whnf (fact @Integer) 20 , bench "Natural" $ whnf (fact @Natural) 20 ] , bgroup "fact2 20" [ bench "Int" $ whnf (fact @Int) 20 , bench "Word" $ whnf (fact @Word) 20 , bench "Int64" $ whnf (fact @Int64) 20 , bench "Word64" $ whnf (fact @Word64) 20 , bench "Integer" $ whnf (fact @Integer) 20 , bench "Natural" $ whnf (fact @Natural) 20 ] ] }}} {{{ benchmarking fact 20/Int time 17.33 ns (17.22 ns .. 17.41 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 17.21 ns (17.16 ns .. 17.29 ns) std dev 222.4 ps (184.5 ps .. 282.3 ps) variance introduced by outliers: 15% (moderately inflated) benchmarking fact 20/Word time 17.25 ns (17.01 ns .. 17.63 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 17.19 ns (17.11 ns .. 17.36 ns) std dev 358.6 ps (199.4 ps .. 674.3 ps) variance introduced by outliers: 32% (moderately inflated) benchmarking fact 20/Int64 time 166.7 ns (165.4 ns .. 168.5 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 166.8 ns (166.0 ns .. 168.5 ns) std dev 4.077 ns (1.854 ns .. 6.592 ns) variance introduced by outliers: 35% (moderately inflated) benchmarking fact 20/Word64 time 560.5 ns (550.6 ns .. 575.0 ns) 0.995 R² (0.989 R² .. 1.000 R²) mean 556.5 ns (549.1 ns .. 575.9 ns) std dev 36.08 ns (9.195 ns .. 60.69 ns) variance introduced by outliers: 78% (severely inflated) benchmarking fact 20/Integer time 421.9 ns (419.8 ns .. 425.3 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 427.7 ns (425.5 ns .. 431.3 ns) std dev 9.238 ns (6.311 ns .. 16.19 ns) variance introduced by outliers: 28% (moderately inflated) benchmarking fact 20/Natural time 534.5 ns (532.6 ns .. 536.3 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 533.7 ns (532.6 ns .. 535.3 ns) std dev 4.535 ns (3.652 ns .. 6.226 ns) benchmarking fact2 20/Int time 17.14 ns (17.07 ns .. 17.23 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 17.15 ns (17.10 ns .. 17.24 ns) std dev 227.1 ps (167.4 ps .. 286.9 ps) variance introduced by outliers: 16% (moderately inflated) benchmarking fact2 20/Word time 16.93 ns (16.86 ns .. 17.02 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 16.90 ns (16.86 ns .. 16.95 ns) std dev 149.8 ps (107.4 ps .. 192.5 ps) benchmarking fact2 20/Int64 time 165.1 ns (164.6 ns .. 165.7 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 164.8 ns (164.5 ns .. 165.1 ns) std dev 1.033 ns (778.6 ps .. 1.363 ns) benchmarking fact2 20/Word64 time 545.3 ns (542.8 ns .. 547.9 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 543.6 ns (542.4 ns .. 545.2 ns) std dev 4.741 ns (3.736 ns .. 5.824 ns) benchmarking fact2 20/Integer time 419.1 ns (417.2 ns .. 421.1 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 418.2 ns (416.8 ns .. 420.2 ns) std dev 5.415 ns (4.094 ns .. 7.147 ns) variance introduced by outliers: 12% (moderately inflated) benchmarking fact2 20/Natural time 533.8 ns (532.2 ns .. 536.1 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 533.2 ns (532.1 ns .. 534.8 ns) std dev 4.428 ns (3.217 ns .. 5.741 ns) }}} In `fact`, `Int` and `Word` are efficient, `Int64` and `Word64` are respectively 10x and 20x slowers, when they should be identical on 64 bit platform. `Word64` is even slower than `Integer`! Replacing `fact` by a handwritten recursion, in `fact2` gives something more coherent where all the 64 bits types have roughly the same efficiency. I observed in the source code that `Int` and `Int64` are not implemented as type synonym. Using `-ddump-rule-firings`, I observed that a rule `fold/build` fired and removed the `fold` for the `Int` case, and not for the `Int64`, I don't understand much ;( This is not dramatic because most people will use `Int` instead of `Int64`, but it is a surprising behavior. I also observed that smaller integral (such as `Int8`, `Int16`, `Int32`) behaves as badly as `Int64`) and this is much more important because there is no other default and more efficient type synonym. Note that I'll be interested to provide a patch myself if mentored a bit. Especially, I'm thinking about merging the `Int` and `Int64` implementation (with respect to the architecture default word size). Tested on GHC 8.4.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16283: StaticPointers pragma changes generated code even when the feature is not used
by GHC 04 Feb '19

04 Feb '19

#16283: StaticPointers pragma changes generated code even when the feature is not used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Tried with GHC HEAD. Program: {{{ module Main where import Control.Concurrent import System.Mem nats :: [Int] nats = [0 .. ] main = do let z = nats !! 400 print z performGC threadDelay 1000000 print (nats !! 900) }}} Compile without any flags: {{{ ==================== Tidy Core ==================== 2019-02-04 09:16:26.121849511 UTC Result size of Tidy Core = {terms: 45, types: 26, coercions: 0, joins: 0/0} -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r1zg :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r1zg = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule2_r1zt :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r1zt = GHC.Types.TrNameS $trModule1_r1zg -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule3_r1zu :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r1zu = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule4_r1zv :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r1zv = GHC.Types.TrNameS $trModule3_r1zu -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] Main.$trModule = GHC.Types.Module $trModule2_r1zt $trModule4_r1zv -- RHS size: {terms: 4, types: 1, coercions: 0, joins: 0/0} nats :: [Int] [GblId] nats = enumFrom @ Int GHC.Enum.$fEnumInt (GHC.Types.I# 0#) -- RHS size: {terms: 22, types: 13, coercions: 0, joins: 0/0} main :: IO () [GblId] main = >> @ IO GHC.Base.$fMonadIO @ () @ () (print @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 400#))) (>> @ IO GHC.Base.$fMonadIO @ () @ () performGC (>> @ IO GHC.Base.$fMonadIO @ () @ () (threadDelay (GHC.Types.I# 1000000#)) (print @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 900#))))) -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () [GblId] :Main.main = GHC.TopHandler.runMainIO @ () main }}} Compile with `-XStaticPointers`: {{{ ==================== Tidy Core ==================== 2019-02-04 09:16:35.678350955 UTC Result size of Tidy Core = {terms: 67, types: 42, coercions: 0, joins: 0/0} -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r1zg :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r1zg = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule2_r1zF :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r1zF = GHC.Types.TrNameS $trModule1_r1zg -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule3_r1zG :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r1zG = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule4_r1zH :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r1zH = GHC.Types.TrNameS $trModule3_r1zG -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] Main.$trModule = GHC.Types.Module $trModule2_r1zF $trModule4_r1zH -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl_r1zI :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl_r1zI = GHC.Types.I# 0# -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} nats :: [Int] [GblId] nats = enumFrom @ Int GHC.Enum.$fEnumInt lvl_r1zI -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl1_r1zJ :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl1_r1zJ = GHC.Types.I# 400# -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl2_r1zK :: Int [GblId] lvl2_r1zK = !! @ Int nats lvl1_r1zJ -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl3_r1zL :: IO () [GblId] lvl3_r1zL = print @ Int GHC.Show.$fShowInt lvl2_r1zK -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl4_r1zM :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl4_r1zM = GHC.Types.I# 1000000# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl5_r1zN :: IO () [GblId] lvl5_r1zN = threadDelay lvl4_r1zM -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl6_r1zO :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl6_r1zO = GHC.Types.I# 900# -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl7_r1zP :: Int [GblId] lvl7_r1zP = !! @ Int nats lvl6_r1zO -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl8_r1zQ :: IO () [GblId] lvl8_r1zQ = print @ Int GHC.Show.$fShowInt lvl7_r1zP -- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} lvl9_r1zR :: IO () [GblId] lvl9_r1zR = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl5_r1zN lvl8_r1zQ -- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} lvl10_r1zS :: IO () [GblId] lvl10_r1zS = >> @ IO GHC.Base.$fMonadIO @ () @ () performGC lvl9_r1zR -- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} main :: IO () [GblId] main = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl3_r1zL lvl10_r1zS -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () [GblId] :Main.main = GHC.TopHandler.runMainIO @ () main }}} Diff: {{{ --- no_static_ptrs/GcStaticPointers.dump-simpl 2019-02-04 12:16:26.120066655 +0300 +++ static_ptrs/GcStaticPointers.dump-simpl 2019-02-04 12:16:35.675924328 +0300 @@ -1,9 +1,9 @@ ==================== Tidy Core ==================== -2019-02-04 09:16:26.121849511 UTC +2019-02-04 09:16:35.678350955 UTC Result size of Tidy Core - = {terms: 45, types: 26, coercions: 0, joins: 0/0} + = {terms: 67, types: 42, coercions: 0, joins: 0/0} -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r1zg :: GHC.Prim.Addr# @@ -11,55 +11,91 @@ $trModule1_r1zg = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} -$trModule2_r1zt :: GHC.Types.TrName +$trModule2_r1zF :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule2_r1zt = GHC.Types.TrNameS $trModule1_r1zg +$trModule2_r1zF = GHC.Types.TrNameS $trModule1_r1zg -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} -$trModule3_r1zu :: GHC.Prim.Addr# +$trModule3_r1zG :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule3_r1zu = "Main"# +$trModule3_r1zG = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} -$trModule4_r1zv :: GHC.Types.TrName +$trModule4_r1zH :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule4_r1zv = GHC.Types.TrNameS $trModule3_r1zu +$trModule4_r1zH = GHC.Types.TrNameS $trModule3_r1zG -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] -Main.$trModule = GHC.Types.Module $trModule2_r1zt $trModule4_r1zv +Main.$trModule = GHC.Types.Module $trModule2_r1zF $trModule4_r1zH --- RHS size: {terms: 4, types: 1, coercions: 0, joins: 0/0} +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl_r1zI :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl_r1zI = GHC.Types.I# 0# + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} nats :: [Int] [GblId] -nats = enumFrom @ Int GHC.Enum.$fEnumInt (GHC.Types.I# 0#) +nats = enumFrom @ Int GHC.Enum.$fEnumInt lvl_r1zI + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl1_r1zJ :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl1_r1zJ = GHC.Types.I# 400# + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl2_r1zK :: Int +[GblId] +lvl2_r1zK = !! @ Int nats lvl1_r1zJ + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl3_r1zL :: IO () +[GblId] +lvl3_r1zL = print @ Int GHC.Show.$fShowInt lvl2_r1zK + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl4_r1zM :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl4_r1zM = GHC.Types.I# 1000000# + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl5_r1zN :: IO () +[GblId] +lvl5_r1zN = threadDelay lvl4_r1zM + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl6_r1zO :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl6_r1zO = GHC.Types.I# 900# + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl7_r1zP :: Int +[GblId] +lvl7_r1zP = !! @ Int nats lvl6_r1zO + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl8_r1zQ :: IO () +[GblId] +lvl8_r1zQ = print @ Int GHC.Show.$fShowInt lvl7_r1zP + +-- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} +lvl9_r1zR :: IO () +[GblId] +lvl9_r1zR + = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl5_r1zN lvl8_r1zQ + +-- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} +lvl10_r1zS :: IO () +[GblId] +lvl10_r1zS + = >> @ IO GHC.Base.$fMonadIO @ () @ () performGC lvl9_r1zR --- RHS size: {terms: 22, types: 13, coercions: 0, joins: 0/0} +-- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} main :: IO () [GblId] -main - = >> - @ IO - GHC.Base.$fMonadIO - @ () - @ () - (print - @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 400#))) - (>> - @ IO - GHC.Base.$fMonadIO - @ () - @ () - performGC - (>> - @ IO - GHC.Base.$fMonadIO - @ () - @ () - (threadDelay (GHC.Types.I# 1000000#)) - (print - @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 900#))))) +main = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl3_r1zL lvl10_r1zS -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16283> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC
by GHC 03 Feb '19

03 Feb '19

#9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | 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: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- First, load the following program into GHCi. '''Fun.hs''' {{{#!hs module Fun where import Language.Haskell.TH stuff = do -- let x = mkName "X" x <- newName "X" sequence $ [dataD (return []) x [] [ normalC x [] ] []] }}} '''thbug.hs''' {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Fun stuff }}} Then comment out the newName, un comment the mkName and reload GHCi. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): kcLookupKind APromotionErr RecDataConPE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is important to note this is a valid program, if you then close GHCi and start it again with the modified file, it will load correctly. Reloading after attempting to compile the newName version will cause a panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9693> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11084: Some type families don't reduce with :kind!
by GHC 03 Feb '19

03 Feb '19

#11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sadly, I'm unable to reproduce this without `singletons`. :( Observe: {{{ > ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Promotion.Prelude -- singletons-2.0.1 Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = Data.Singletons.Prelude.List.Case_1628035408 'True 'True 'True '[] (Data.Singletons.Apply (Data.Singletons.Apply (:==$) 'True) 'True) Prelude Data.Promotion.Prelude> :kind! Lookup 'True '[ '(True, True) ] Lookup 'True '[ '(True, True) ] :: Maybe Bool = JustSym1 'True }}} Note that the exact same command run twice yields different results. I tried peeking at `-ddump-tc-trace` but got nothing of use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11084> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2