- ghc-devs - Haskell.org

Inferring instance constraints with DeriveAnyClass
by Ryan Scott 21 Jun '16

21 Jun '16

Andres, I'm trying to think of a proper solution to Trac #12144 [1]. This bug triggers when you try to use DeriveAnyClass in a somewhat exotic fashion: {-# LANGUAGE DeriveAnyClass, KindSignatures #-} class C (a :: * -> *) data T a = MkT (a -> Int) deriving C This currently gives a GHC panic: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): contravariant This baffled me until I realized why it's happening: for typeclasses of kind * -> *, DeriveAnyClass simply re-uses the same algorithm that DeriveFunctor uses for coming up with an instance context. For instance, if you have: data T f a = MkT a (f a) deriving (Functor, C) Then it would generate two instances of the form: instance Functor f => Functor (T f) where ... instance C f => C (T f) where ... But #12144 reveals the fatal downside of doing this: DeriveFunctor has special knowledge about type parameters in contravariant positions, but this doesn't even make sense to think about with a class like C! (The only reason GHC won't panic if a Functor instance is derived for T is because there are Functor-specific checks that cause an error message to pop up before the panic can be reached.) My question is then: why does DeriveAnyClass take the bizarre approach of co-opting the DeriveFunctor algorithm? Andres, you originally proposed this in #7346 [2], but I don't quite understand why you wanted to do it this way. Couldn't we infer the context simply from the contexts of the default method type signatures? This is a question that Reid Barton has also asked, to which José Pedro Magalhães answered in the negatory [3]. But Pedro's reasoning has never quite made sense to me, because we've been able to typecheck constraints arising from default method type signatures for a long time, so why would it be impractical to do so in this case? I'd appreciate hearing a more detailed explanation on this issue, because at the moment, I am completely stuck on figuring out how one might fix #12144. Regards, Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12144 [2] https://ghc.haskell.org/trac/ghc/ticket/7346 [3] https://ghc.haskell.org/trac/ghc/ticket/5462#comment:30

4 6

Simon's email classified as spam
by Simon Peyton Jones 19 Jun '16

19 Jun '16

Dear GHC devs/users This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience once more? Just let me know if this email ends up in your inbox or spam. Can you cc John and Gershom (but perhaps not everyone else)? Thanks Simon | From: Gershom B [mailto:gershomb@gmail.com] | Sent: 18 June 2016 18:53 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; John Wiegley | <johnw(a)newartisans.com> | Cc: Michael Burge <michaelburge(a)pobox.com> | Subject: Re: FW: CMM-to-SAM: Register allocation weirdness | | Simon — I just found two possible sources of the problem (first: the top | level config didn’t take hold due to other errors when updating — fixed that, | and second, it might be possible the top level config isn’t retroactively | applied to all lists — so i added the config to the relevant lists directly). | | I think if you try one more time it might work (fingers crossed).

2 1

CMM-to-ASM: Register allocation wierdness
by Carter Schonwald 19 Jun '16

19 Jun '16

Agreed. There's also some other mismatches between ghc and llvm in a few fun / interesting ways! There's a lot of room for improvement in both code gens, but there's also a lot of room to improve the ease of experimenting with improvements. Eg we don't have a peephole pass per target, so those get hacked into the pretty printing code last time I checked On Thursday, June 16, 2016, Ben Gamari <ben(a)smart-cactus.org <javascript:_e(%7B%7D,'cvml','ben(a)smart-cactus.org');>> wrote: > > Ccing David Spitzenberg, who has thought about proc-point splitting, which > is relevant for reasons that we will see below. > > > Harendra Kumar <harendra.kumar(a)gmail.com> writes: > > > On 16 June 2016 at 13:59, Ben Gamari <ben(a)smart-cactus.org> wrote: > >> > >> It actually came to my attention while researching this that the > >> -fregs-graph flag is currently silently ignored [2]. Unfortunately this > >> means you'll need to build a new compiler if you want to try using it. > > > > Yes I did try -fregs-graph and -fregs-iterative both. To debug why > nothing > > changed I had to compare the executables produced with and without the > > flags and found them identical. A note in the manual could have saved me > > some time since that's the first place to go for help. I was wondering > if I > > am making a mistake in the build and if it is not being rebuilt > > properly. Your note confirms my observation, it indeed does not change > > anything. > > > Indeed; I've opened D2335 [1] to reenable -fregs-graph and add an > appropriate note to the users guide. > > >> All-in-all, the graph coloring allocator is in great need of some love; > >> Harendra, perhaps you'd like to have a try at dusting it off and perhaps > >> look into why it regresses in compiler performance? It would be great if > >> we could use it by default. > > > > Yes, I can try that. In fact I was going in that direction and then > stopped > > to look at what llvm does. llvm gave me impressive results in some cases > > though not so great in others. I compared the code generated by llvm and > it > > perhaps did a better job in theory (used fewer instructions) but due to > > more spilling the end result was pretty similar. > > > For the record, I have also struggled with register spilling issues in > the past. See, for instance, #10012, which describes a behavior which > arises from the C-- sinking pass's unwillingness to duplicate code > across branches. While in general it's good to avoid the code bloat that > this duplication implies, in the case shown in that ticket duplicating > the computation would be significantly less code than the bloat from > spilling the needed results. > > > But I found a few interesting optimizations that llvm did. For example, > > there was a heap adjustment and check in the looping path which was > > redundant and was readjusted in the loop itself without use. LLVM either > > removed the redundant _adjustments_ in the loop or moved them out of the > > loop. But it did not remove the corresponding heap _checks_. That makes > me > > wonder if the redundant heap checks can also be moved or removed. If we > can > > do some sort of loop analysis at the CMM level itself and avoid or remove > > the redundant heap adjustments as well as checks or at least float them > out > > of the cycle wherever possible. That sort of optimization can make a > > significant difference to my case at least. Since we are explicitly aware > > of the heap at the CMM level there may be an opportunity to do better > than > > llvm if we optimize the generated CMM or the generation of CMM itself. > > > Very interesting, thanks for writing this down! Indeed if these checks > really are redundant then we should try to avoid them. Do you have any > code you could share that demosntrates this? > > It would be great to open Trac tickets to track some of the optimization > opportunities that you noted we may be missing. Trac tickets are far > easier to track over longer durations than mailing list conversations, > which tend to get lost in the noise after a few weeks pass. > > > A thought that came to my mind was whether we should focus on getting > > better code out of the llvm backend or the native code generator. LLVM > > seems pretty good at the specialized task of code generation and low > level > > optimization, it is well funded, widely used and has a big community > > support. That allows us to leverage that huge effort and take advantage > of > > the new developments. Does it make sense to outsource the code generation > > and low level optimization tasks to llvm and ghc focussing on higher > level > > optimizations which are harder to do at the llvm level? What are the > > downsides of using llvm exclusively in future? > > > > There is indeed a question of where we wish to focus our optimization > efforts. However, I think using LLVM exclusively would be a mistake. > LLVM is a rather large dependency that has in the past been rather > difficult to track (this is why we now only target one LLVM release in a > given GHC release). Moreover, it's significantly slower than our > existing native code generator. There are a number of reasons for this, > some of which are fixable. For instance, we currently make no effort to > tell > LLVM which passes are worth running and which we've handled; this is > something which should be fixed but will require a rather significant > investment by someone to determine how GHC's and LLVM's passes overlap, > how they interact, and generally which are helpful (see GHC #11295). > > Furthermore, there are a few annoying impedance mismatches between Cmm > and LLVM's representation. This can be seen in our treatment of proc > points: when we need to take the address of a block within a function > LLVM requires that we break the block into a separate procedure, hiding > many potential optimizations from the optimizer. This was discussed > further on this list earlier this year [2]. It would be great to > eliminate proc-point splitting but doing so will almost certainly > require cooperation from LLVM. > > Cheers, > > - Ben > > > [1] https://phabricator.haskell.org/D2335 > [2] https://mail.haskell.org/pipermail/ghc-devs/2015-November/010535.html >

1 0

Re: Optimizing "counting" GADTs
by David Feuer 19 Jun '16

19 Jun '16

Partially. Unfortunately, bidirectional pattern synonyms tie the types of the pattern synonyms to the types of the smart constructors for no good reason, making them (currently) inappropriate. But fixing that problem would offer one way to this optimization, I think. On May 25, 2016 8:37 PM, "Carter Schonwald" <carter.schonwald(a)gmail.com> wrote: could this be simulated/modeled with pattern synonyms? On Wed, May 25, 2016 at 7:51 PM, David Feuer <david.feuer(a)gmail.com> wrote: > I've started a wiki page, > https://ghc.haskell.org/trac/ghc/wiki/OptimizeCountingGADTs , to consider > optimizing GADTs that look like natural numbers but that possibly have > "heavy zeros". Please take a look. > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >

4 7

Force GC calls out of the straight line execution path
by Harendra Kumar 17 Jun '16

17 Jun '16

Hi, I noticed in the generated code (llvm as well as native) that in some cases the GC calls are in the straight path and the regular code is out of the straight line path. Like this: => 0x408fc0: lea 0x30(%r12),%rax => 0x408fc5: cmp 0x358(%r13),%rax => 0x408fcc: jbe 0x408fe9 # notice jbe instead of ja i.e. branch taken in normal case I tried to count in how many cases its happening in my executable and found that its only a small percentage (4-6%) of cases but those cases include the code which runs 99% of the time in my benchmark. Though it does not make a whole lot of difference but the difference is perceptible and especially when it is in a tight loop. Is it possible to somehow force all the GC calls out of the line during code generation? Has it been thought/discussed before? -harendra

3 4

ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by Nicolas Dudebout 16 Jun '16

16 Jun '16

When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash. Default behavior: $ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Correct behavior (no trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Incorrect behavior (with trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" When this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}. This bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator)

2 1

CoreToStg Asserts
by Phyx 15 Jun '16

15 Jun '16

Hi *, I'm hoping someone could help me understand what the asserts in CoreToStg on line 240 and 216 are trying to tell me. I hit both of them while trying to compile libraries as dyn. WARNING: file compiler\stgSyn\CoreToStg.hs, line 250 $trModule2 False True ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 8.1.20160612 for x86_64-unknown-mingw32): ASSERT failed! file compiler\stgSyn\CoreToStg.hs line 216 $trModule2 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug WARNING: file compiler\simplCore\SimplCore.hs, line 633 Simplifier bailing out after 4 iterations [6737, 736, 51, 9] Size = {terms: 12,990, types: 9,998, coercions: 443} WARNING: file compiler\stgSyn\CoreToStg.hs, line 250 $fEqBigNat_$c/= False True ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 8.1.20160612 for x86_64-unknown-mingw32): ASSERT failed! file compiler\stgSyn\CoreToStg.hs line 240 [$fEqBigNat_$c/=, $fEqBigNat] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Kind Regards, Tamar

4 4

Re: ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by Ryan Scott 15 Jun '16

15 Jun '16

Good catch! This seems like a straightforward bug. Do you mind creating a ticket for this issue on GHC Trac at https://ghc.haskell.org/trac/ghc/newticket ? Best, Ryan S.

1 0

Pusing to haddock
by Simon Peyton Jones 14 Jun '16

14 Jun '16

Devs, I want to push to the haddock repo, to fix the build. But I can’t. .git/modules/utils/haddock/ contains [remote "origin"] url = git://git.haskell.org/haddock.git pushurl = ssh://git@git.haskell.org/haddock.git fetch = +refs/heads/*:refs/remotes/origin/* I’m on branch ghc-head. But when I push I get /cygdrive/c/code/HEAD/utils/haddock$ git push remote: W refs/heads/ghc-head haddock simonpj DENIED by refs/.* remote: error: hook declined to update refs/heads/ghc-head To ssh://git@git.haskell.org/haddock.git ! [remote rejected] ghc-head -> ghc-head (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/haddock.git' No info on WHY it rejected. What now? I attach the patch if someone else would like to push. If you do, update ghc HEAD to match Simon

5 8

haddock
by Simon Peyton Jones 13 Jun '16

13 Jun '16

Ah! I forgot to push a one-line difff to haddock, which is breaking the build. Sorry. Gotta go right now but will do tonight. Meanwhile all should be ok if you swtich off Haddock Simon

1 0