- ghc-tickets - Haskell.org

[GHC] #11739: Simplify axioms; should be applied to types
by GHC 12 Dec '16

12 Dec '16

#11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Simon PJ says: In `Note [Coercion axioms applied to coercions]` in Coercion, we find the justification for allowing coercions as arguments to axioms. The goal is to add a bit of extra expressiveness, so that optimisations can be done pair-wise. But the example shows that the new expressiveness is not expressive enough! Rather than give up (as you do in !OptCoercion) maybe we should re-examine the assumption. How could we optimise if axioms could only be instantiated with types, not coercions. Which would be a LOT simpler! Let's take the example from the Note: {{{ C a : t[a] ~ F a g : b ~ c }}} and we want to optimize {{{ sym (C b) ; t[g] ; C c :: F b ~ F c }}} One possibility is to perform a 3-component optimisation, but that's a bit horrible. But what about this: push the `t[g]` ''past'' the axiom rather than ''into'' it. For example {{{ t[g] ; C c ==> C b ; F g where t[g] : t[b]~t[c] C c : t[c] ~ F c }}} If we use this to move axioms to the right, I think we'll get the same optimisations as now, but with a simpler system. Does that seem right? Now it becomes clearer that you can't always commute the things. {{{ ax : F a a ~ a; F a b ~ b co :: Id Bool ~ Bool }}} If we have {{{ (F <Int> co ; ax[1] Int Bool) : F Int (Id Bool) ~ Bool }}} then we might try to commute `co` past the axiom thus: {{{ ax[1] Int (Id Bool) ; co }}} but now (as you point out) the ax[1] is not necessarily OK. But I hazard that the lack of the commuting isn't going to lose useful optimisations. So in some ways we are no further forward (an optimisation is only sometimes OK), but I feel MUCH happier about simplifying the axiom- applied-to-coercion stuff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #876: Length is not a good consumer
by GHC 12 Dec '16

12 Dec '16

#876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: fixed | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12960: New haddock seems to be segfaulting
by GHC 12 Dec '16

12 Dec '16

#12960: New haddock seems to be segfaulting -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 61932cd3eb0d5d22cb35d118fb9f87298881cd77 bumped up haddock. This seems to be segfaulting randomly on Windows and OSX or just dies. compiler/ghc.mk:581: recipe for target 'compiler/stage2/doc/html/ghc/ghc.haddock' failed make[1]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12960> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12961: Duplicate exported functions?
by GHC 12 Dec '16

12 Dec '16

#12961: Duplicate exported functions? -------------------------------------+------------------------------------- Reporter: nomeata | Owner: 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In my paper on Call Arity, I wrote > Unfortunately it also means that adding a top-level function to the export list of the module can prevent Call Arity from eta-expanding it and other functions in the module. and a reviewer asked > Why don’t you duplicate and specialize the function? And that is an interesting question, which I don’t want to pursue at the moment in detail, but note down. Obviously, if the the function can be inlined in all uses in the current module, we essentially do that already. But if not (for example, because it is recursive), then this could indeed improve the performance of the in-module uses. The question is: Is it worth it? Questions on the way: Do we have more analyses like Call Arity that gather information form the use sites, and that need to make pessimistic assumptions for exported functions, or is it the only one? In terms of final code size: Will CSE reliably undo the duplication of possible large swathes of code if both copies of the function were compiled identically? Maybe instead of duplicating all exported functions opportunistically, Call Arity could analyze them twice and only if it gets useful data from the use-sites cause them to be duplicated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12961> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #876: Length is not a good consumer
by GHC 11 Dec '16

11 Dec '16

#876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This code, compiled with `-O, does fuse, and allocates nothing (or constant amounts) {{{#!hs module Foo where x :: Int -> Int x n = length [0..(10^n)::Int] }}} {{{ $ ghci -fobject-code -O Foo GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo. Prelude Foo> :set +s Prelude Foo> x 1 11 (0.03 secs, 14,976,744 bytes) Prelude Foo> x 7 10000001 (0.02 secs, 0 bytes) Prelude Foo> x 8 100000001 (0.04 secs, 0 bytes) }}} (almost) HEAD: {{{ GHCi, version 8.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo (.hs -> .o) WARNING: file compiler/simplCore/SimplCore.hs, line 663 Simplifier bailing out after 4 iterations [58, 14, 2, 2] Size = {terms: 96, types: 32, coercions: 0} Ok, modules loaded: Foo (Foo.o). Prelude Foo> :set +s Prelude Foo> x 1 11 (0.19 secs, 94,792 bytes) Prelude Foo> x 2 101 (0.01 secs, 94,648 bytes) Prelude Foo> x 7 10000001 (0.01 secs, 98,568 bytes) Prelude Foo> x 8 100000001 (0.05 secs, 98,448 bytes) }}} Testing this in with interpreted code is not sufficient, as the optimizer does less in that case. So so far, everything seems as expected to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #915: Implement list fusion using streams instead of foldr/build
by GHC 11 Dec '16

11 Dec '16

#915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Given the preceding comment by Duncan does it make sense to reopen this as a potential task? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/915#comment:47> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #876: Length is not a good consumer
by GHC 11 Dec '16

11 Dec '16

#876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: closed => new * resolution: fixed => Comment: I believe this has regressed. {{{ length [0..10] 11 it :: Int (0.11 secs, 85,536 bytes) Prelude> length [0..(10^7)] 10000001 it :: Int (0.25 secs, 720,084,176 bytes) Prelude> }}} My guess, fwiw, is that this is connected with AMP, making list an instance of Foldable and the issue that rewrite rules cannot be applied to class methods as discussed in recent emails between Conal and SimonPJ. I think the current priority of lowest is correct but thought it worth noting that the problem still exists. Also I think that the user's guide does not accurately reflect the state of list fusion, i.e. https://ghc.haskell.org/trac/ghc/ticket/915. The User's Guide, section 9.32.6 states "This list could readily be extended; if there are Prelude functions that you use a lot which are not included, please tell us." As this bug and ticket 915 indicates extending the list is not always easy. I can file a doc bug if people would like. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2
by GHC 11 Dec '16

11 Dec '16

#12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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): Phab:D2749 | Wiki Page: -------------------------------------+------------------------------------- Bump up the bindists to have a more up to date gcc and binutils. The updated binutils should fix LLVM backend on 64bit Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7289: Mingw FPU init not Windows compatible.
by GHC 10 Dec '16

10 Dec '16

#7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => patch * differential: => Phab:D2819 * architecture: x86 => Unknown/Multiple -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7289#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7206: Implement cheap build
by GHC 10 Dec '16

10 Dec '16

#7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I took another look at this while waiting for a build and I believe I have identified the source of the additional allocations. In particular I looked at the `real/parser` nofib case, which regresses in allocations by about 3% when using `cheapBuild` for `unpack`, {{{ "unpack" [~1] forall a . unpackCString# a = cheapBuild (unpackFoldrCString# a) }}} The issue is replicated with an example as simple as, {{{#!hs module Hi where data Pat = PatVar Id | PatCon Id [Pat] | PatWild | PatTuple [Pat] deriving (Show{-was:Text-}) type Id = String }}} A pattern which occurs quite often in `parser`. Let's consider the code generated for the `PatTuple` branch of `$cshowsPrec` (taken from the output of the phase 1 simplifier pass), {{{#!hs -- Before cheapBuild PatTuple b1 -> case a of { GHC.Types.I# x -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# x 11#) of { False -> ++ @ Char lvl (GHC.Show.showList__ @ Pat $cshowList b1 eta); True -> GHC.Types.: @ Char GHC.Show.shows6 (++ @ Char lvl (GHC.Show.showList__ @ Pat $cshowList b1 (GHC.Types.: @ Char GHC.Show.shows4 eta))) } } -- After cheapBuild PatTuple b1 -> let { p :: ShowS p = \ (x :: String) -> GHC.CString.unpackAppendCString# "PatTuple "# (GHC.Show.showList__ @ Pat $cshowList b1 x) } in case a of { GHC.Types.I# x -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# x 11#) of { False -> p eta; True -> GHC.Types.: @ Char GHC.Show.shows6 (p (GHC.Types.: @ Char GHC.Show.shows4 eta)) } } }}} We see that after the introduction of `cheapBuild` the `p` binding is no longer inlined. Comparing the output of `dump-inlinings` reveals why, **Before `cheapBuild`** {{{ Considering inlining: p arg infos [ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [0] 80 0 discounted size = 60 ANSWER = YES Inlining done: p Inlined fn: \ (x :: GHC.Base.String) -> GHC.Base.++ @ GHC.Types.Char lvl (GHC.Types.: @ GHC.Types.Char GHC.Show.shows5 (GHC.Show.showLitString b1 (GHC.Types.: @ GHC.Types.Char GHC.Show.shows5 x))) Cont: ApplyToVal nodup (GHC.Types.: @ GHC.Types.Char GHC.Show.shows4 x) Stop[BoringCtxt] [GHC.Types.Char] }}} **After `cheapBuild`** {{{ Considering inlining: p arg infos [ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [0] 110 0 discounted size = 90 ANSWER = NO }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7206#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0