- ghc-tickets - Haskell.org

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by simonpj): Why `Int#`? Wouldn't `Word#` be a better fit? We already have logical operations on that type. Can you summarise the design you have implemented, on the Wiki page [http://hackage.haskell.org/trac/ghc/wiki/PrimBool]? it's a bit hard to reverse-engineer it from the patch. Many thanks. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7447: Stale .hi files affect compilation.
by GHC 13 Mar '13

13 Mar '13

#7447: Stale .hi files affect compilation. ------------------------------------------------+--------------------------- Reporter: int-e | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect warning at compile-time | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------------------------+--------------------------- Changes (by parcs): * status: new => closed * resolution: => fixed Comment: This is what I get with current HEAD: {{{ > echo 'module Peaker(L(..)) where{ data V = V {-# UNPACK #-} !L; data L = L V }' > Peaker.hs > ghc -fforce-recomp -O1 Peaker.hs [1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o ) > ghc -fforce-recomp -O1 Peaker.hs [1 of 1] Compiling Peaker ( Peaker.hs, Peaker.o ) > }}} The warning is no longer produced at all, which I think is the correct behavior because there is no reason that L shouldn't be able to get unpacked into V. So I think it's OK to close the ticket. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7447#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): > So a solid +1 for me for implementing something like this, > although maybe not with the names in the patch? Names are definitely open for discussion. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by gregorycollins): > One possible use of unboxed booleans is branchless search. There are some algorithms where you can replace branches (e.g. case statements) with bit twiddling operators. I believe Gregory Collins used one such trick in the hashtables package. Didn't see this before now. Yes, this is true, part of the reason I wrote the cache-line-sized hash code search is that I couldn't get efficient straight-line code out of GHC for doing it. One very useful bit-twiddling hack that the processor can do but GHC can't: int mask(int a, int b) { return -(a == b); } The C code gives me this: {{{ xorl %eax, %eax cmpl %esi, %edi sete %al negl %eax }}} The Haskell code gives me code with branches because of the case on `Bool`, which I couldn't figure out how to get rid of. I did manage to get straight-line code for a pure Haskell function with the same semantics, but at a cost of about twice as many instructions. Interestingly, getting rid of the branch here, even in the roundabout way the Haskell version did it, was worth O(30%) on hash table lookup (it's in an inner loop). The C version I wrote for cache line-sized hash code lookups was good for another 20-30% besides that, and I chalked up the difference to this comparison issue with Bool and much better register allocation on the C side. (GHC was spilling even when it seemed there were many free 64-bit registers). So a solid +1 for me for implementing something like this, although maybe not with the names in the patch? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

RE: [GHC] #7766: equality constraints exposed by patterns mess up constraint inference
by Simon Peyton-Jones 13 Mar '13

13 Mar '13

You probably need do { (case .... of ...) :: IO () ; return () } It's not a bug, in other words. The "modular type inference with local constraints" paper is a good reference here. Simon | -----Original Message----- | From: Gabor Greif [mailto:ggreif@gmail.com] | Sent: 13 March 2013 15:05 | To: ghc-devs(a)haskell.org; Simon Peyton-Jones | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7766: equality constraints exposed by patterns mess | up constraint inference | | Hi Simon, | | okay, I see how a type signature will help in that case, but it is | unclear where to add one in this (even simpler) example: | | | {-# LANGUAGE GADTs, DataKinds, KindSignatures #-} | | data Nat = S Nat | Z | | data Nat' (n :: Nat) where | S' :: Nat' n -> Nat' (S n) | Z' :: Nat' Z | | main :: IO () | main = do case S' Z' of | (S' Z') -> putStrLn "yep" -- see error message below... | -- _ -> putStrLn "yep" -- works! | return () | | {- | [1 of 1] Compiling Main ( pr7766.hs, pr7766.o ) | | pr7766.hs:11:23: | Couldn't match type `a0' with `()' | `a0' is untouchable | inside the constraints (n ~ 'Z) | bound by a pattern with constructor | Z' :: Nat' 'Z, | in a case alternative | at pr7766.hs:11:16-17 | Expected type: IO a0 | Actual type: IO () | In the return type of a call of `putStrLn' | In the expression: putStrLn "yep" | In a case alternative: (S' Z') -> putStrLn "yep" | -} | | | Can we reopen the PR with this test? (Distilled from real code I have | and which fails as of recently.) | | Thanks and cheers, | | Gabor | | On 3/13/13, GHC <cvs-ghc(a)haskell.org> wrote: | > #7766: equality constraints exposed by patterns mess up constraint | > inference | > ----------------------------------------+----------------------------- | > ----------------------------------------+------ | > Reporter: heisenbug | Owner: | > Type: bug | Status: closed | > Priority: normal | Milestone: | > Component: Compiler | Version: 7.7 | > Resolution: invalid | Keywords: | > Os: Unknown/Multiple | Architecture: | Unknown/Multiple | > Failure: GHC rejects valid program | Difficulty: Unknown | > Testcase: | Blockedby: | > Blocking: | Related: | > ----------------------------------------+----------------------------- | > ----------------------------------------+------ | > Changes (by simonpj): | > | > * status: new => closed | > * difficulty: => Unknown | > * resolution: => invalid | > | > | > Comment: | > | > This is by design. Type inference in the presence of GADTs is | tricky! | > | > If you give the signature `main :: IO ()` it works fine. But here | > you are asking GHC to ''infer'' the type of `main`. (Remember, | > Haskell doesn't insist on `IO ()`; the `main` function can have type | > `IO Char`.) | > | > Becuase you are pattern matching against GADTs there are equalities | > in scope, so GHC declines to contrain the type of `main`. In this | > particular case there is only one answer, but that's very hard to | > figure out, so we fail conservatively. | > | > Bottom line: use type signatures when pattern matching on GADTs. | > | > Simon | > | > -- | > Ticket URL: | > <http://hackage.haskell.org/trac/ghc/ticket/7766#comment:1> | > GHC <http://www.haskell.org/ghc/> | > The Glasgow Haskell Compiler | >

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Changes (by jstolarek): * status: new => patch -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 13 Mar '13

13 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Comment(by jstolarek): I implemented a prototype version of new comparison primops. They compare two `Int#`s but as a result they return either `0#` (denoting False) or `1#` (denoting True) instead of returning a `Bool`. Now the results of comparing can be combined using bitwise `orI#`, `andI#`, `xorI#` and `notI#` primops, which addresses the original problem that was reported (at least partially). I'm attaching patches for GHC and the testsuite (includes some cleanup of my other code for testing primops). These patches are for review and discussion purposes - they are not yet ready for integration because they don't contain primops for comparing values of type `Word#`, `Float#` and `Double#`. I will implement comparisons for these types once I am certain that I got things right with `Int#`. Feedback will be much appreciated. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7557: Default implementation for a type class function missing when profiling is enabled
by GHC 13 Mar '13

13 Mar '13

#7557: Default implementation for a type class function missing when profiling is enabled -------------------------------+-------------------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: invalid | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: infoneeded => closed * resolution: => invalid Comment: OK, I think I'll just close it then. Sorry! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7557#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 13 Mar '13

13 Mar '13

#5987: Too many symbols in ghc package DLL -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: 3658 | Related: -------------------------------+-------------------------------------------- Comment(by simonpj): Great. Are there some Wiki notes or comments in the code to explain the thinking, what the problem is, how it is solved, where the partioning is done, how you managed to factor GHC into two? Etc. This kind of global info can be hard to find. Indeed is there a wiki page surveying the whole dynamic-linking question and how we address it? I can't find it if so. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5987#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7766: equality constraints exposed by patterns mess up constraint inference
by GHC 13 Mar '13

13 Mar '13

#7766: equality constraints exposed by patterns mess up constraint inference --------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC rejects valid program | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- When patterns bring (equality) constraints into scope, the inference mechanism for other (unrelated) constraints breaks down. This is a new problem that appeared between * ghc-7.7.20121025 and * ghc-7.7.20121114 I can try to track down the commit if that helps. Testcase against HEAD attached. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1