July 2015 - ghc-tickets

[GHC] #10351: Inferred type is rejected
by GHC 09 Jul '15

09 Jul '15

#10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ class C a where op :: a -> () f x = op [x] }}} we get {{{ Foo.hs:14:1: error: Non type-variable argument in the constraint: C [t] (Use FlexibleContexts to permit this) When checking that ‘f’ has the inferred type f :: forall t. C [t] => t -> () }}} Arguably, if `FlexibleContexts` is not on, we should not infer a type that will immediately be rejected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10351> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2439: Missed optimisation with dictionaries and loops
by GHC 09 Jul '15

09 Jul '15

#2439: Missed optimisation with dictionaries and loops -------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I can't say I understand what is going on here, but in reify/reflect it seems that you want something akin to a local instance declaration. You want to write: {{{ reify (x :: a) (\ (p :: Proxy s) -> ...In here we have (Reifies s a)... ) }}} And you want to supply the local instance of `(Reifies s a)` yourself. Isn't this just what implicit parameters are for? They give you local instance declarations, in effect. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2439#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10606: avoid redundant stores to the stack when examining already-tagged data
by GHC 09 Jul '15

09 Jul '15

#10606: avoid redundant stores to the stack when examining already-tagged data -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (CodeGen) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHC compiles a function that performs case analysis on a value of an ADT like {{{ bool :: a -> a -> Bool -> a bool f t b = case b of False -> f True -> t }}} to Cmm of the form {{{ {offset cwV: if ((Sp + -24) < SpLim) goto cwW; else goto cwX; cwW: R4 = R4; R3 = R3; R2 = R2; R1 = Bool.bool_closure; call (stg_gc_fun)(R4, R3, R2, R1) args: 8, res: 0, upd: 8; cwX: I64[Sp - 24] = cwL; -- (*) R1 = R4; P64[Sp - 16] = R2; -- (†1) P64[Sp - 8] = R3; -- (†2) Sp = Sp - 24; -- (‡) if (R1 & 7 != 0) goto cwL; else goto cwM; cwM: call (I64[R1])(R1) returns to cwL, args: 8, res: 8, upd: 8; cwL: if (R1 & 7 >= 2) goto cwT; else goto cwU; cwT: R1 = P64[Sp + 16]; Sp = Sp + 24; call stg_ap_0_fast(R1) args: 8, res: 0, upd: 8; cwU: R1 = P64[Sp + 8]; Sp = Sp + 24; call stg_ap_0_fast(R1) args: 8, res: 0, upd: 8; } }}} Statement (*) stores a return address for the evaluation of `b` to return to, and statements (†1), (†2) save local variables that are live in case alternatives, since they cannot be held in registers across the evaluation of `b`. But in the event that `b` is already evaluated and represented by a tagged pointer, all these stores are unnecessary: the return address written by (*) is simply dead, and the values saved in (†1), (†2) are still available in whatever locations they were copied to the stack from. In many cases the data we examine is mostly tagged, and while the active part of the stack is likely to be in L1 cache, the cost of these stores and reads is probably still positive (barring secondary effects from changes to pipelining, branch prediction, and so on). In this case we could certainly move the return address store (*) into block `cwM`, and possibly move the local variable stores (†1), (†2) into `cwM` as well, though it's then not clear to me how to recover the values in the alternatives (does Cmm have something like phi nodes?) I don't propose to move the statement (‡), as arithmetic on registers is essentially free anyways. I tried implementing the part of this pertaining to the return address (*) and ran into two complications. * For some reason, when I moved the return address store (*) into the "data is not tagged" branch in the Stg->Cmm translation, this also resulted in both the local variable stores (†1), (†2) and the update to Sp (‡) being sunk into both branches of the "is the data tagged" conditional at some point in the Cmm optimization pipeline. This was useless since they couldn't be pushed further past the branch on the returned tag value, so the result was enlarged code size that outweighed the savings of avoiding a single store. I didn't investigate exactly why this sinking was dependent on the location of the store (*), but this should be fixable. * There may be heap checks in the alternatives. In that case, the code generator currently cleverly reuses the stack frame and info table set up for the evaluation of `b` in the heap failure branches. If we move some of the stores (*), (†1), (†2) into the evaluation branch `cwM`, then we either have to duplicate them in heap failure branches, or set up a new stack frame and info table, or do some other clever thing. Or in the worst case, only do this optimization when performing the heap check before the case (which may then become slightly more attractive). I'm attaching the current version of my patch mainly for my own future reference; it seems to produce correct, but larger and marginally slower code, I believe for the reasons described above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 09 Jul '15

09 Jul '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"b29633f5cf310824f3e34716e9261162ced779d3/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b29633f5cf310824f3e34716e9261162ced779d3" Bitmap: Fix thunk explosion Previously we would build up another `map (-N)` thunk for every word in the bitmap. Now we strictly accumulate the position and carry out a single ``map (`subtract` accum)``. `Bitmap.intsToBitmap` showed up in the profile while compiling a testcase of #7450 (namely a program containing a record type with large number of fields which derived `Read`). The culprit was `CmmBuildInfoTables.procpointSRT.bitmap`. On the testcase (with 4096 fields), the profile previously looked like, ``` total time = 307.94 secs (307943 ticks @ 1000 us, 1 processor) total alloc = 336,797,868,056 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc lintAnnots CoreLint 17.2 25.8 procpointSRT.bitmap CmmBuildInfoTables 11.3 25.2 FloatOutwards SimplCore 7.5 1.6 flatten.lookup CmmBuildInfoTables 4.0 3.9 ... ``` After this fix it looks like, ``` total time = 256.88 secs (256876 ticks @ 1000 us, 1 processor) total alloc = 255,033,667,448 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc lintAnnots CoreLint 20.3 34.1 FloatOutwards SimplCore 9.1 2.1 flatten.lookup CmmBuildInfoTables 4.8 5.2 pprNativeCode AsmCodeGen 3.7 4.3 simplLetUnfolding Simplify 3.6 2.2 StgCmm HscMain 3.6 2.1 ``` Signed-off-by: Ben Gamari <ben(a)smart-cactus.org> Test Plan: Validate Reviewers: austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1041 GHC Trac Issues: #7450 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)?
by GHC 09 Jul '15

09 Jul '15

#7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1012 -------------------------------------+------------------------------------- Comment (by bgamari): ticket:9669#comment:13 contains a summary of the performance impact of Phab:D1012 and Phab:D1040 on this and potentially-related ticket #7258. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7450#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2439: Missed optimisation with dictionaries and loops
by GHC 08 Jul '15

08 Jul '15

#2439: Missed optimisation with dictionaries and loops -------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Here's a worked version of the `SNat` thing I was talking about: {{{ {-# LANGUAGE RankNTypes, TypeOperators, GADTs, DataKinds #-} module SNat where import GHC.TypeLits import Unsafe.Coerce data SNat n where SNat :: KnownNat n => SNat n snatVal :: SNat n -> Integer snatVal n@SNat = natVal n instance Show (SNat n) where showsPrec d n = showsPrec d (snatVal n) newtype Magic n = Magic (KnownNat n => SNat n) add :: SNat n -> SNat m -> SNat (n + m) add n m = unsafeCoerce (Magic SNat) (snatVal n + snatVal m) mul :: SNat n -> SNat m -> SNat (n * m) mul n m = unsafeCoerce (Magic SNat) (snatVal n * snatVal m) }}} With that at the ghci prompt we can now look at `SNat`'s {{{ ghci> SNat :: SNat 32 32 }}} and I can work around the limitations of the nat solver, by helping it out as needed at the value level: {{{ ghci> add (SNat :: SNat 1) (SNat :: SNat 2) 3 }}} Then if I need the fabricated `KnownNat` instance for the sum I can just open up my `SNat` constructor and bring it into scope, like the Show instance just did. Here I had to make up my own `SNat` type as the one that is provided by GHC is actually not exported. `add` and `mul` are evil and unsafe, but here they do precisely the right thing. Their results are correct, even if the methodology is suspect. We get them by coercing `Magic n` into a function and passing it the value that is the representation of KnownNat. The core that gets generated is just that of explicit dictionary passing, same as with reflection. With `reflection` I relied on the quantifier when reifying to ensure things were generative. Here I rely on the fact that I'm working with singleton values, but the mechanism used to cheat the system is the same. The current `reflection` code looks similar, just using a different `Magic` type and some quantifier and `Proxy` noise to permit use in more situation. {{{ class Reifies s a | s -> a where reflect :: proxy s -> a newtype Magic a r = Magic (forall (s :: *). Reifies s a => Proxy s -> r) -- | Reify a value at the type level, to be recovered with 'reflect'. reify :: forall a r. a -> (forall (s :: *). Reifies s a => Proxy s -> r) -> r reify a k = unsafeCoerce (Magic k :: Magic a r) (const a) Proxy }}} In a world that was modified to make all dictionaries live inside a data type so they could be forced without consequence then I'd be changing `reify` to something more like: {{{ data Dictionary a = Dictionary a reify :: forall a r. a -> (forall (s :: *). Reifies s a => Proxy s -> r) -> r reify a k = unsafeCoerce (Magic k :: Magic a r) (Dictionary (const a)) Proxy }}} assuming that the dictionary representation and the representation of a data type with exactly one field (like `Dictionary`) were the same. I could patch around it if needed, but the proposal here seems odd to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2439#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10618: HEAD@d71b65f53a panics: ``get_op (--$)''
by GHC 08 Jul '15

08 Jul '15

#10618: HEAD@d71b65f53a panics: ``get_op (--$)'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- (Note that 7.10.1 works as expected) This one line generates a panic: {{{#!hs panic = GarbageConstructorName $ a --$ b }}} (in an otherwise blank file, when passed to {{{ghc }}} or {{{ghci}}}. Just the right hand side panics {{{ghci}}} interactively.) Error message: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150708 for x86_64-unknown-linux): get_op (--$) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{uname -a: Linux cam-05-unx 3.5.0-54-generic #81~precise1-Ubuntu SMP Tue Jul 15 04:02:22 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux}}} {{{ gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program- suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable- libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable- objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable- checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) }}} With {{{ghc -v}}} (Was built with {{{BuildFlavour = devel2}}}, default {{{build.mk}}} otherwise): {{{ Glasgow Haskell Compiler, Version 7.11.20150708, stage 2 booted by GHC version 7.8.2 Using binary package database: /5playpen/t-bepric/ghc- build/inplace/lib/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace wired-in package base mapped to base-4.8.2.0-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-inplace wired-in package ghc mapped to ghc-7.11.20150708-inplace wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-inplace wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-inplace wired-in package base mapped to base-4.8.2.0-inplace wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-inplace wired-in package ghc mapped to ghc-7.11.20150708-inplace wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *GetOpCrash.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-07-08 15:09:13 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file GetOpCrash.hs Created temporary directory: /tmp/ghc22576_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( GetOpCrash.hs, GetOpCrash.o ) *** Parser: *** Renamer/typechecker: *** Deleting temp files: Deleting: /tmp/ghc22576_0/ghc_1.s Warning: deleting non-existent /tmp/ghc22576_0/ghc_1.s *** Deleting temp dirs: Deleting: /tmp/ghc22576_0 ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150708 for x86_64-unknown-linux): get_op (--$) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2439: Missed optimisation with dictionaries and loops
by GHC 08 Jul '15

08 Jul '15

#2439: Missed optimisation with dictionaries and loops -------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): You don't give an actual example, and my brain is too small to reconstruct the code you have in mind. Still, I do agree that wrapping a single value in a data type carries an indirection cost. We could make GHC strict in non-single-method dictionaries; indeed that's the way it's supposed to work right now. But someone needs to actually try it out, benchmark etc. In short, I'm in no hurry to make this change. Meanwhile, it's a crime that you have to fake this stuff up. The more concrete your examples of what you can't do type-securely, the more likely someone is to fix them. At the moment I am clueless. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2439#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2439: Missed optimisation with dictionaries and loops
by GHC 08 Jul '15

08 Jul '15

#2439: Missed optimisation with dictionaries and loops -------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) Comment: @simonpj: Right now the reflection library (and a few other less savory libraries of mine) rely on the internals of a dictionary with one member and that member being the same thing so I can `unsafeCoerce` to build one. An example outside of the `reflection` library where we need to be able to build a dictionary out of whole cloth: {{{ data SNat (n :: Nat) where Snat :: KnownNat n => SNat n }}} Even if in a context we know `(KnownNat n, KnownNat m)`, we still can't derive `KnownNat (n + m)` with the current Nat solver. Yet having an operator {{{ (+) :: SNat n -> SNat m -> SNat (n + m) }}} for adding such `SNat`'s at the value level makes sense and things like that are important for many (if not most) applications of having a type level natural number type. I wind up having to backfill these things in by constructing dictionaries by hand. In theory, if I had to, I could start to rely on, say, it being the same as a one member data type instead if we decided to make that transition, so long as I have something available to me that has the right form that I could `unsafeCoerce` into a dictionary. Regarding performance impact: it'd introduce an extra pointer-dereference everywhere for dictionaries like `KnownNat` or `Reifies`, which currently just carry an `Integer` or a value in newtype form, but now would have an extra reference involved. It is not terribly significant, assuming light usage, but it is not free. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2439#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds)
by GHC 08 Jul '15

08 Jul '15

#5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds) -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: closed Type: bug | Milestone: Priority: normal | Version: 7.0.3 Component: Compiler | Keywords: Resolution: fixed | performance, MonoLocalBinds Operating System: Linux | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | perf/should_run/T5113 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The new `substExprS` was dropping rules and specialisations, which is terribly wrong. So I backed out and fixed #10527 another way; see the commit comments. I'm getting a small number of apparently-unrelated validate failures, but I figure it's better to push this so that Ben can try it out. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5113#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0