May 2018 - ghc-tickets

[GHC] #14062: Pure syntax transformation affects performance.
by GHC 23 Oct '18

23 Oct '18

#14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- Hi! Let's consider the following code (compiled with `-O2`, `mtl` and `criterion` needed): {{{#!hs module Main where import Prelude as import Criterion.Main import Control.Monad.State.Strict import Control.Monad.Identity repeatM :: Monad m => m a -> Int -> m () repeatM f = go where go 0 = pure () go i = f >> go (i - 1) {-# INLINE repeatM #-} incState :: MonadState Int m => m () incState = modify' (1+) ; {-# INLINE incState #-} test1, test2 :: Int -> Int test1 = \n -> (runIdentity . flip evalStateT 0 . (\a -> repeatM incState a >> S.get)) n ; {-# INLINE test1 #-} test2 = \n -> runIdentity . flip evalStateT 0 $ repeatM incState n >> get ; {-# INLINE test2 #-} main :: IO () main = do defaultMain [ bgroup "monad transformers overhead" [ bench "test1" $ nf test1 100000000 , bench "test2" $ nf test2 100000000 ] ] }}} Functions `test1` and `test2` differ only syntactically and this difference should not affect GHC's inliner, because their implementations use fully saturated calls. The generated core for `test1` and `test2` is practically identical (there is an additional alias created for `test1`: `test1 = lvl1_rhor 'cast' ...`). The problem is that `test1` runs **3 times faster** than `test2`. As a side note - if we add more state transformers to `test1`, it optimizes them all away, while `test2` runs slower with each new transformer applied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14980: Runtime performance regression with binary operations on vectors
by GHC 23 Oct '18

23 Oct '18

#14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: vector | Operating System: Unknown/Multiple bitwise operations | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let me briefly explain our use case: we have a machine learning tools created in Haskell. Basically it builds association rules for a database. In plain English: predicates on data rows. We need to score them, so we need to check how many rows are "matched" by the predicate. In order to optimize performance, our code uses two main representations for data: one is a "human readable", where a values are real values. The second one is binarized representation for categorical data. The latter has is actually a family of representation, since we pack bits into tuples of Word64 and use bitwise operation to implement logic. Simplified but representative code is attached. In GHC 8.0.2 binary representation is faster by one order of magnitude than the "human readable" one: {{{ ➜ ghc-bug stack exec performance-bug-pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 342.6 μs (338.3 μs .. 348.0 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 339.3 μs (337.5 μs .. 342.0 μs) std dev 7.203 μs (5.596 μs .. 10.07 μs) variance introduced by outliers: 13% (moderately inflated) benchmarking 256 columns/binary packed time 32.07 μs (29.69 μs .. 34.14 μs) 0.982 R² (0.976 R² .. 0.997 R²) mean 29.97 μs (29.41 μs .. 31.03 μs) std dev 2.428 μs (1.526 μs .. 3.750 μs) variance introduced by outliers: 78% (severely inflated) }}} In GHC 8.2.2 (and later) binary representation performance is similar to "human readable", so no performance gain: {{{ ➜ ghc-bug stack exec performance-bug-pair-1 "Generated" benchmarking 256 columns/raw unbox vectors time 442.4 μs (406.7 μs .. 474.5 μs) 0.978 R² (0.969 R² .. 0.993 R²) mean 399.3 μs (391.3 μs .. 415.1 μs) std dev 34.73 μs (20.36 μs .. 53.29 μs) variance introduced by outliers: 71% (severely inflated) benchmarking 256 columns/binary packed time 378.6 μs (295.8 μs .. 488.0 μs) 0.637 R² (0.492 R² .. 0.780 R²) mean 568.1 μs (437.1 μs .. 747.6 μs) std dev 308.7 μs (233.6 μs .. 386.1 μs) variance introduced by outliers: 98% (severely inflated) }}} However, for certain compilation paths, we still can get similar speedup as with GHC 8.0.2. In the above examples we used 4-tuple of Word64 as binary representation. In the following code we run two tests: one on just Word64 and one of 4-tuple of Word64. The difference is that we just add the Word64 case: {{{ ➜ ghc-bug stack exec performance-bug-pair-2 "Generated" benchmarking 64 columns/raw unbox vectors time 337.6 μs (336.1 μs .. 339.3 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 349.6 μs (344.4 μs .. 359.7 μs) std dev 23.22 μs (15.39 μs .. 38.22 μs) variance introduced by outliers: 60% (severely inflated) benchmarking 64 columns/binary packed time 21.66 μs (21.53 μs .. 21.79 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 21.68 μs (21.53 μs .. 21.89 μs) std dev 613.2 ns (466.0 ns .. 806.0 ns) variance introduced by outliers: 30% (moderately inflated) benchmarking 256 columns/raw unbox vectors time 344.5 μs (341.6 μs .. 348.2 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 345.1 μs (342.5 μs .. 349.3 μs) std dev 10.66 μs (7.997 μs .. 16.34 μs) variance introduced by outliers: 25% (moderately inflated) benchmarking 256 columns/binary packed time 28.04 μs (27.70 μs .. 28.46 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 28.05 μs (27.85 μs .. 28.30 μs) std dev 758.2 ns (628.2 ns .. 907.6 ns) variance introduced by outliers: 27% (moderately inflated) }}} I made a variant of code with simpler accumulating function (in our code we accumulate pair of integers, simplified accumulator work on one integer). GHC 8.2.2 in that case losses speed-up with 4-tuples: {{{ ➜ ghc-bug stack exec performance-bug-2 "Generated" benchmarking 64 columns/raw unbox vectors time 333.8 μs (333.0 μs .. 335.1 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 333.6 μs (332.4 μs .. 335.8 μs) std dev 5.651 μs (3.233 μs .. 9.582 μs) benchmarking 64 columns/binary packed time 39.06 μs (38.98 μs .. 39.14 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 38.94 μs (38.83 μs .. 39.14 μs) std dev 495.0 ns (310.2 ns .. 782.1 ns) benchmarking 256 columns/raw unbox vectors time 336.9 μs (336.2 μs .. 337.9 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 337.5 μs (336.2 μs .. 339.8 μs) std dev 5.757 μs (2.946 μs .. 8.979 μs) benchmarking 256 columns/binary packed time 239.8 μs (237.6 μs .. 243.0 μs) 0.998 R² (0.996 R² .. 0.999 R²) mean 251.4 μs (247.9 μs .. 259.8 μs) std dev 11.50 μs (5.662 μs .. 19.79 μs) variance introduced by outliers: 37% (moderately inflated) }}} In GHC 8.0.2 we have speed-up in both cases. What may be related: using random-fu to generate random numbers seems to produce broken code on GHC 8.2.2 (the `performance-bug-rfu.hs` source). Short description of attached sources: - performance-bug-pair-2.hs: using two binary representations - performance-bug-pair-1.hs: using one binary representation (one case commented) - performance-bug-1.hs: using one binary representation with simplified accumulator - performance-bug-2.hs: using two binary representation with simplified accumulator - performance-bug-rfu.hs: using random-fu to generate data (optional) - stack-8.0.yaml: stack file for GHC-8.0.2 - stack-8.2.yaml: stack file for GHC-8.2.2 - stack-nightly.yaml: stack file for GHC-8.4 - performance-bug.cabal: to be able to stack build everything. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #15201: GHC 8.4 fails to build on Debian s390x
by GHC 22 Oct '18

22 Oct '18

#15201: GHC 8.4 fails to build on Debian s390x --------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -lffi -optl-pthread -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.4.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.13.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.5.0 -package-id ghc-boot-8.4.3 -package-id ghc-boot- th-8.4.3 -package-id ghci-8.4.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.1 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this- unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc- DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/GhcPrelude.hs -o compiler/stage1/build/GhcPrelude.o /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:7:1: error: warning: parameter names (without types) in function declaration | 7 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:8:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes' EB_(ghc_GhcPrelude_zdtrModule4_bytes); ^ | 8 | EB_(ghc_GhcPrelude_zdtrModule4_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:6:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 6 | char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:10:6: error: error: 'ghczmprim_GHCziTypes_TrNameS_con_info' undeclared here (not in a function) (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 10 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule4_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_TrNameS_con_info); ^~~ | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:13:1: error: warning: parameter names (without types) in function declaration | 13 | EI_(ghczmprim_GHCziTypes_TrNameS_con_info); | ^ In file included from /tmp/ghcf6ae_0/ghc_3.hc:3:0: error: /tmp/ghcf6ae_0/ghc_3.hc:14:5: error: error: conflicting types for 'ghc_GhcPrelude_zdtrModule2_bytes' EB_(ghc_GhcPrelude_zdtrModule2_bytes); ^ | 14 | EB_(ghc_GhcPrelude_zdtrModule2_bytes); | ^ includes/Stg.h:236:37: error: note: in definition of macro 'EB_' #define EB_(X) extern const char X[] ^ | 236 | #define EB_(X) extern const char X[] | ^ /tmp/ghcf6ae_0/ghc_3.hc:12:6: error: note: previous definition of 'ghc_GhcPrelude_zdtrModule2_bytes' was here char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 12 | char ghc_GhcPrelude_zdtrModule2_bytes[] = "GhcPrelude"; | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes ^ | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:16:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule1_closure[0]') | 16 | (W_)&ghczmprim_GHCziTypes_TrNameS_con_info, (W_)&ghc_GhcPrelude_zdtrModule2_bytes | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: data definition has no type or storage class EI_(ghczmprim_GHCziTypes_Module_con_info); ^~~ | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:18:1: error: warning: parameter names (without types) in function declaration | 18 | EI_(ghczmprim_GHCziTypes_Module_con_info); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule1_closure); ^~~ | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:19:1: error: warning: parameter names (without types) in function declaration | 19 | EI_(ghc_GhcPrelude_zdtrModule1_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: data definition has no type or storage class EI_(ghc_GhcPrelude_zdtrModule3_closure); ^~~ | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: type defaults to 'int' in declaration of 'EI_' [-Wimplicit- int] | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:20:1: error: warning: parameter names (without types) in function declaration | 20 | EI_(ghc_GhcPrelude_zdtrModule3_closure); | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:6: error: error: 'ghczmprim_GHCziTypes_Module_con_info' undeclared here (not in a function); did you mean 'ghczmprim_GHCziTypes_TrNameS_con_info'? (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ghczmprim_GHCziTypes_TrNameS_con_info | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: error: initializer element is not constant (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL ^ | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ /tmp/ghcf6ae_0/ghc_3.hc:22:1: error: note: (near initialization for 'ghc_GhcPrelude_zdtrModule_closure[0]') | 22 | (W_)&ghczmprim_GHCziTypes_Module_con_info, ((W_)&ghc_GhcPrelude_zdtrModule3_closure+1), ((W_)&ghc_GhcPrelude_zdtrModule1_closure+1), 0x3UL | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=s390x&ver=8.4.3-1&s… -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14909: Change default armhf target to a newer architecture
by GHC 21 Oct '18

21 Oct '18

#14909: Change default armhf target to a newer architecture -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the default [https://github.com/ghc/ghc/blob/60b06456ddef08bd8a8a47497a6cbefbb5e359fb /llvm-targets#L4 llvm-targets] file specifies the default `arm-unknown- linux-gnueabihf` target to be using `-mcpu=arm1176jzf-s`. Which is an `Armv6` architecture. This has the problem that it's generating memory barriers using `CP15` instructions that are deprecated in `Armv7` and removed in `Armv8`. Because of this there's no way to run the binaries being produced by GHC HQ on Armv8 CPUs without having kernel support for `CP15 Barrier emulation.` which is slow. We're also not taking advantage of new Armv8 instructions this way. The debian folks have a bug report about this as well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864847 This means that GHC cannot work on most boards people have/can easily buy today. I think the default target should be an `Armv7` architecture at the very least. But realistically `Armv8` would probably be ok as well as I doubt many people use GHC to compile on older cores. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14461: Reuse free variable lists through nested closures
by GHC 21 Oct '18

21 Oct '18

#14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 7258 Differential Rev(s): | Wiki Page: NestedClosures -------------------------------------+------------------------------------- Consider [wiki:NestedClosures] and [ticket:7258]; essentially, deeply nested closures exhibit quadratic compiler performance due to the fact that when allocating registers, each nesting level will have the compiler unpack the entire parent closure and then re-pack the variables into the child closure. To solve this, check if the parent closure can be carried along wholesale, and pull variables from there so that the repackaging can be bypassed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #14971: Use appropriatly sized comparison instruction for small values.
by GHC 21 Oct '18

21 Oct '18

#14971: Use appropriatly sized comparison instruction for small values. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: (CodeGen) | 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: -------------------------------------+------------------------------------- GHC currently defaults all comparisons originating from Cmm switch statements to 64bit on x64. This incurs a small overhead in instruction size. Fixing this manually gave a speedup of ~1,5% in microbenchmarks. In detail we generate Cmm of the form: {{{ _s8Dg::P64 = R1; _c8EF::P64 = _s8Dg::P64 & 7; switch [1 .. 2] _c8EF::P64 { case 1 : goto c8Ey; case 2 : goto c8EC; } }}} Which results in assembly like: {{{ andl $7,%ebx cmpq $1,%rbx }}} It's obvious that c8EF fits into a byte, but is sized up to 64 bits. Changing this would enable us to use cmpl instead of cmpq and save us a byte on each comparison. While this isn't major in my microbenchmarks it resultet in a speedup of ~1,5% for such constructs in inner loops. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14830: Use test instead of cmp for comparison against zero.
by GHC 20 Oct '18

20 Oct '18

#14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: (NCG) | 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: -------------------------------------+------------------------------------- For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86. However using test leads to slightly smaller code. (Saves a byte per comparison). A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions. From there it should be not too hard to track down the required changes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'
by GHC 18 Oct '18

18 Oct '18

#15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ % cat Nopie.hs module Nopie where main :: IO () main = putStrLn "hi" % ghc -fforce-recomp -c -fhpc Nopie.hs clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] }}} This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output. Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11307: Regresssion: parsing type operators
by GHC 17 Oct '18

17 Oct '18

#11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- GHC 7.10.3 will parse (but not type-check) the following {{{#!hs {-# LANGUAGE TypeOperators #-} type family (r1 :++: r2); infixr 5 :++: type instance r :++: Nil = r type instance r1 :++: r2 :> a = (r1 :++: r2) :> a }}} Current master (c7830bdb14e0a85a78617314156d101155fdf7aa) fails with {{{#!hs /tmp/Foo.hs:5:15: error: Malformed head of type or class declaration: r1 :++: r2 :> a }}} @simonpj comment on ghc-devs mailing list > `| type instance r1 :++: r2 :> a = (r1 :++: r2) :> a` > > What do you expect this to mean? I suppose you could hope that GHC will > unravel the fixity of :++: and :>, to determine whether you are giving an > instance for :++: or for :>? > > That sounds reasonable, but it's not trivial. > > Currently the LHS of a 'type instance' decl is ultimately a TyFamEqn, and > it looks like this: > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_tycon :: Located name > , tfe_pats :: pats > , tfe_rhs :: LHsType name } > }}} > > So we've already decided (in the parser) what the type-function name is. > But we can't do that in this case, because the parser doesn't understand > fixity. > > To deal with this we'd need to change to > > {{{#!hs > data TyFamEqn name pats > = TyFamEqn > { tfe_lhs :: LHSType name > , tfe_rhs :: LHsType name } > }}} > > so that the LHS was just a type. Now the renamer can re-jiggle its > fixities in the usual way, and only in the type checker will we need to > decide exactly which type it's an instance of. Easy! > > This might be a good change to make! It's a bit like in ClsInstDecl, you'll > see that the instance cid_poly_ty is just a LHsSigType, i.e. not decomposed > into which class it is. > -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13600: surprising error message with bang pattern
by GHC 15 Oct '18

15 Oct '18

#13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the following code {{{ f3 :: [Int] -> IO Int f3 x = return (sum x) f4 :: [Int] -> IO Int f4 !x = return (sum x) }}} gives `The type signature for ‘f4’ lacks an accompanying binding` for the second function (the two functions are exactly the same except for the added bang). I do not understand bang patterns well, but would expect a more instructive error message. without the type definition, the second function f4 compiles with the bang). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20