December 2016 - ghc-tickets

[GHC] #12943: Adjust AST to capture additional parens around a context
by GHC 08 Dec '16

08 Dec '16

#12943: Adjust AST to capture additional parens around a context -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #3384 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment the parser strips redundant parens around a context when constructing the AST. So the following two definitions would end up with the same AST. {{{#!hs foo :: (Show a) => a -> String foo' :: ((Show a)) => a -> String }}} This causes roundtripping of an AST via `ppr` to fail, and adds complexity to the API Annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10371: GHC fails to inline and specialize a function
by GHC 08 Dec '16

08 Dec '16

#10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have an alternative Prelude library called [subhask](https://github.com/mikeizbicki/subhask) that redefines the numeric type class hierarchy. I'm trying to update it to work with GHC 7.10, but there is a major inlining bug that is killing performance. The code below demonstrates the issue. It first defines a distance function over 2 vectors, then measures the performance using criterion. (It requires the subhask to compile.) {{{ {-# LANGUAGE BangPatterns #-} import Control.DeepSeq import Criterion.Main import qualified Data.Vector.Unboxed as VU import qualified Data.Vector.Generic as VG import qualified Prelude import SubHask -- distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float distance_standalone v1 v2 = sqrt $ go 0 0 where go !tot !i = if i>VG.length v1-4 then goEach tot i else go tot' (i+4) where tot' = tot +(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) +(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) *(v1 `VG.unsafeIndex` (i+1)-v2 `VG.unsafeIndex` (i+1)) +(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) *(v1 `VG.unsafeIndex` (i+2)-v2 `VG.unsafeIndex` (i+2)) +(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) *(v1 `VG.unsafeIndex` (i+3)-v2 `VG.unsafeIndex` (i+3)) goEach !tot !i = if i>= VG.length v1 then tot else goEach tot' (i+1) where tot' = tot+(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) *(v1 `VG.unsafeIndex` i-v2 `VG.unsafeIndex` i) main = do let v1 = VU.fromList [1..200] :: VU.Vector Float v2 = VU.fromList [1..200] :: VU.Vector Float deepseq v1 $ deepseq v2 $ return () defaultMain [ bench "distance_standalone" $ nf (distance_standalone v1) v2 ] }}} Here are the results of compiling and running using GHC 7.10 and 7.8: {{{ $ ghc-7.10.1 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 8.135 μs (8.121 μs .. 8.154 μs) 1.000 R² (1.000 R² .. 1.000 R²) mean 8.188 μs (8.158 μs .. 8.250 μs) std dev 139.3 ns (66.05 ns .. 250.4 ns) variance introduced by outliers: 15% (moderately inflated) }}} {{{ $ ghc-7.8.2 Main.hs -O2 -fforce-recomp -ddump-to-file -ddump-simpl && ./Main [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... benchmarking distance_standalone time 733.2 ns (732.9 ns .. 733.6 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 734.1 ns (733.7 ns .. 734.5 ns) std dev 1.458 ns (1.262 ns .. 1.754 ns) }}} As you can see, GHC 7.10 is 10x slower. Looking through the core output shows that the cause of this is that GHC 7.8 is properly specializing the code whereas GHC 7.10 is not. If you uncomment the type signature before the `distance_standalone` function then both compilers perform at the faster speed. I believe the cause of this may be related to the complicated class numeric class hierarchy in SubHask. If you comment out the lines: {{{ import qualified Prelude import SubHask }}} then GHC uses the Prelude hierarchy instead of SubHask's hierarchy, and both compilers generate the faster program. There's one last wrinkle. If you define the `distance_standalone` function in a different file. Then in GHC 7.10, the `INLINE` and `INLINABLE` pragmas do absolutely nothing. Not only does the resulting code not get inlined, but if I add the specialization: {{{ {-# SPECIALIZE distance_standalone :: VU.Vector Float -> VU.Vector Float -> Float #-} }}} to the Main file, I get an error message saying something like: {{{ bench/Vector.hs:18:1: Warning: You cannot SPECIALISE ‘distance_standalone{v ru1}’ because its definition has no INLINE/INLINABLE pragma (or its defining module ‘subhask-0.1.0.0@subha_LNZiQvSbo8Z0VdLTwuvkrN:SubHask.Algebra’ was compiled without -O) }}} I get this message despite the fact that the defining module was compiled with `-O2` and the function had an `INLINABLE` pragma. If I add the specialization pragma to the defining module, then I don't get the warning, but the code still doesn't specialize properly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10371> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 08 Dec '16

08 Dec '16

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by danharaj): * differential: => Phab:D2714 Comment: My patch for #12791 also resolves this issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 08 Dec '16

08 Dec '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2
by GHC 08 Dec '16

08 Dec '16

#12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- Following code if compiled with -O2 (but not -O1) causes assertion failure. Depends only on vector. {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} module A where import GHC.Base import qualified Data.Vector.Unboxed.Base import qualified Data.Vector.Generic.Base import Data.Vector.Generic.Mutable import qualified Data.Vector.Generic.Mutable.Base import Data.Vector.Generic (fromList) data A = A Int Int Int instance Data.Vector.Unboxed.Base.Unbox A newtype instance Data.Vector.Unboxed.Base.MVector s_a4iX A = MV_A (Data.Vector.Unboxed.Base.MVector s_a4iX (Int, Int, Int)) instance MVector Data.Vector.Unboxed.Base.MVector A where basicLength (MV_A v) = basicLength v basicUnsafeSlice idx len (MV_A v) = MV_A (basicUnsafeSlice idx len v) basicUnsafeNew len = (MV_A `liftM` (basicUnsafeNew len)) basicUnsafeWrite (MV_A v) idx val_a4iW = basicUnsafeWrite v idx ( (\ (A a_a4iT b_a4iU c_a4iV) -> (a_a4iT, b_a4iU, c_a4iV)) val_a4iW) newtype instance Data.Vector.Unboxed.Base.Vector A = V_A (Data.Vector.Unboxed.Base.Vector (Int, Int, Int)) instance Data.Vector.Generic.Base.Vector Data.Vector.Unboxed.Base.Vector A where mkA :: Data.Vector.Unboxed.Base.Vector A mkA = fromList [] }}} {{{ ghc: panic! (the 'impossible' happened) [7/1644] (GHC version 8.1.20161202 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 eta_X1T $cbasicUnsafeFreeze_a6sr $cbasicUnsafeThaw_a6st $cbasicLength_a6sv $cbasicUnsafeSlice_a6sx $cbasicUnsafeIndexM_a6sz $cbasicUnsafeCopy_a6sF $celemseq_a6t3 $cbasicLength_a6tm $cbasicUnsafeSlice_a6ty $cbasicOverlaps_a6tL $cbasicUnsafeNew_a6tN $cbasicInitialize_a6uj $cbasicUnsafeReplicate_a6up $cbasicUnsafeRead_a6uJ $cbasicUnsafeWrite_a6uL $cbasicClear_a6vg $cbasicSet_a6vE $cbasicUnsafeCopy_a6w2 $cbasicUnsafeMove_a6wr $cbasicUnsafeGrow_a6wQ wild_a7QO dt_a7QQ ds1_a7QR ds2_a7QS ds3_a7QT wild_a80U x_a819 xs1_a81a ds4_a84V z_a84W s7_a84X ds5_a851 wild5_a85V v3_a85X i_a85Y wild7_a866 x_a868 y_a86k wild9_a86m $tcA $trModule $tc'A $fVectorVectorA $fUnboxA $fMVectorMVectorA mkA $cbasicUnsafeSlice_s7QF $trModule_s7Su $trModule_s7Sv $tc'A_s7Sw $s$dmbasicUnsafeGrow_s7Vp $s$dmbasicUnsafeMove_s7Vw $s$dmbasicUnsafeReplicate_s7VB $s$dmbasicSet_s7VG $s$dmbasicUnsafeCopy_s7VN $s$dmbasicUnsafeCopy_s7VW $sunstream_s886 $s$fMVectorMVector(,,)_$cbasicUnsafeNew_s896 $s$fMVectorMVector(,,)_$cbasicUnsafeWrite_s89h $s$fMVectorMVector(,,)_$cbasicUnsafeSlice_s89k $s$fMVectorMVector(,,)_$cbasicLength_s89l $sfromList_s89m $snew_s89n $s$dmelemseq_s89o $s$dmbasicClear_s89p lvl_s89Y $j_sa8p lvl_sbhM lvl_sbhN lvl_sbhO lvl_sbhP lvl_sbhQ lvl_sbhR lvl_sbhT lvl_sbhU lvl_sbhV lvl_sbhW lvl_sbi1 lvl_sbi2 lvl_sbi4 lvl_sbi5 lvl_sbi6 lvl_sbi7 foldlM_loop_sbns foldlM_loop_sbnL lvl_sbo2 $sfoldlM_loop_sbHS $s$j_sbI5 $sfoldlM_loop_sbIa $sfoldlM_loop_sbIx} tenv [] tenvFVs [] cenv [sbHY :-> sg_sbHY] cenvFVs [sbHY :-> sg_sbHY] tys [PrimState (ST RealWorld)] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12926> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 08 Dec '16

08 Dec '16

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by danharaj): * owner: => danharaj -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5835: Make better use of known dictionaries
by GHC 08 Dec '16

08 Dec '16

#5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5835#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 08 Dec '16

08 Dec '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman <alan.zimm@…>): In [changeset:"499e43824bda967546ebf95ee33ec1f84a114a7c/ghc" 499e438/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="499e43824bda967546ebf95ee33ec1f84a114a7c" Add HsSyn prettyprinter tests Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9320: Inlining regression/strangeness in 7.8
by GHC 08 Dec '16

08 Dec '16

#9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- A couple days ago, it was reported to me that vector-algorithms had a significant performance regression (~20x) on GHC 7.8.2. The problem stems from a lack of inlining and specialization of some of the functions that were previously handled in 7.6 and earlier. The following is a reduced test case (the vector and primitive packages are required): {{{ module A (test) where import Control.Monad.ST import Control.Monad import Control.Monad.Primitive import Data.Vector.Generic.Mutable as U test :: (PrimMonad m, MVector v a, Num a) => Int -> v (PrimState m) a -> m a -- test :: (MVector v a, Num a) => Int -> v s a -> ST s a test 0 v = liftM (+1) $ unsafeRead v 0 test n v = do long1 v test (n-1) v {-# INLINABLE test #-} long1, long2, long3, long4 :: (PrimMonad m, MVector v a) => v (PrimState m) a -> m () long1 v = long2 v >> long2 v >> long2 v >> long2 v long2 v = long3 v >> long3 v >> long3 v >> long3 v long3 v = long4 v >> long4 v >> long4 v >> long4 v long4 v = unsafeRead v 0 >>= unsafeWrite v 0 {-# INLINE long1 #-} {-# INLINE long2 #-} {-# INLINE long3 #-} {-# INLINE long4 #-} }}} {{{ module Main (main) where import Control.Monad.ST import Data.Vector.Unboxed.Mutable as U hiding (read) import System.Environment import Unsafe.Coerce import GHC.Prim import A test0 :: Int -> MVector s Int -> ST s Int test0 n v = test n v {-# NOINLINE test0 #-} test1' :: Int -> MVector Any Int -> ST Any Int test1' n v = test n v {-# NOINLINE test1 #-} test1 :: Int -> MVector a Int -> ST a Int test1 = unsafeCoerce test1' main = getArgs >>= \(n:b:_) -> print $ runST $ do v <- new 1 write v 0 0 (if read b then test0 else test1) (read n) v }}} Module `A` exports a single function, `test`. This function is engineered to be quite large, by inlining several other functions into it, and it is itself marked INLINABLE. Then the `Main` module uses this function in two different ways: * `test0` uses `test` at a type that is compatible with `runST` * `test1'` uses `test` at a completely monomorphic type, which is then coerced to a `runST` compatible type in `test1` On 7.6 I believe (though have not checked) that there will be little or no performance difference between `test0` and `test1`. However, on 7.8.2 (and, I have been assured, 7.8.3), there is a massive speed pentalty for `test0`; about 70x on my machine. This seems to be due to no inining or specialization for its use of `test`, which can be seen from `-ddump- simpl`. However, if one changes the type of `test` in `A` to be specific to `ST s` rather than using `PrimMonad`, there is no performance difference, even on 7.8.2. So, the choice to inline and specialize seems to hinge on the instantiation of all the class constraints to monomorphic types containing no variables, rather than just types that resolve all overloading. I myself did not notice this problem, because my benchmark suite uses `IO`, which is a concrete instantiation of the type, and doesn't exhibit this problem. I have temporarily 'fixed' vector-algorithms by moving back to `INLINE` pragmas, but `INLINABLE` is actually preferable in that case, because it generates faster code than `INLINE` when the optimizations actually fire. My test case here does not illustrate that well, though. Is it safe to assume that this was not an intentional change? It's a rather weird rule (to me) if it was. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8668: SPECIALIZE silently fails to apply
by GHC 08 Dec '16

08 Dec '16

#8668: SPECIALIZE silently fails to apply ----------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- I have a small example where GHC refuses to specialize a call to `(+)`, compiling with -O2. The two files are Foo.hs (http://lpaste.net/98464) and Main.hs (http://lpaste.net/98342) There seem to be two problems: 1. The active `SPECIALIZE` pragma should be applied, but isn't. This can be seen by comparing the core and runtimes of `fcTest` (slow) vs `vtTest` (fast). I need this version of the pragma in my real code as the phantom type `m` is reified, so I need to specialize the vector code without specifying the phantom type. 2. I can get `fcTest` to run fast if I use the commented-out `SPECIALIZE` pragma instead. However, that pragma seems very straightforward to me (all types are concrete). The docs indicate that GHC should automatically specialize in most cases, why does it not specialize to the commented-out signature automatically? This problem is also posted here: http://stackoverflow.com/questions/21071706/specialization-with- constraints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8668> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26