February 2017 - ghc-tickets

Re: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions
by GHC 02 Feb '17

02 Feb '17

#2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double, newcomer 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 rwbarton): * keywords: rules, performance, double => rules, performance, double, newcomer Comment: Namely, {{{ double f(unsigned long x) { return x; } /* 0000000000000000 <f>: 0: 66 48 0f 6e cf movq %rdi,%xmm1 5: 66 0f 62 0d 00 00 00 punpckldq 0x0(%rip),%xmm1 # d <f+0xd> c: 00 9: R_X86_64_PC32 .LCPI0_0-0x4 d: 66 0f 5c 0d 00 00 00 subpd 0x0(%rip),%xmm1 # 15 <f+0x15> 14: 00 11: R_X86_64_PC32 .LCPI0_1-0x4 15: 66 0f 70 c1 4e pshufd $0x4e,%xmm1,%xmm0 1a: 66 0f 58 c1 addpd %xmm1,%xmm0 1e: c3 retq */ }}} Compiling the test program here with LLVM there's no measurable difference between the int and word versions, so I guess doing this is worthwhile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2269#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2269: Word type to Double or Float conversions are slower than Int conversions
by GHC 02 Feb '17

02 Feb '17

#2269: Word type to Double or Float conversions are slower than Int conversions -------------------------------------+------------------------------------- Reporter: dons | Owner: dons@… Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: rules, | performance, double 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 rwbarton): Replying to [comment:16 thomie]: > But `testWord` is still 3 times slower than `testInt`. > {{{ > $ time ./testWord > 5.00000005e15 > > real 0m0.579s > user 0m0.575s > sys 0m0.003s > > $ time ./testInt > 5.00000005e15 > > real 0m0.196s > user 0m0.191s > sys 0m0.004s > }}} > > As I can not easily explain this difference, I'll leave this ticket open for now. It's because the x86 NCG implements the new `MO_UF_Conv` as a call to a C function, rather than generating code inline like `MO_SF_Conv` (`cvtsi2sdq`). Unfortunately there's no corresponding instruction for converting an unsigned 64-bit integer to float or double, but for converting to double the code generated by `clang -O` is pretty small and simple and probably worth inlining. It will still be somewhat slower than `Int` though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2269#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'll look forward to the proposal. It's a remarkably small patch! Don't forget to add comprehensive tests etc. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13224: Rules and join points
by GHC 02 Feb '17

02 Feb '17

#13224: Rules and join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Note [Rules and join points] in `OccurAnal`: Things get fiddly with rules. Suppose we have: {{{ let j :: Int -> Int j y = 2 * y k :: Int -> Int -> Int {-# RULES "SPEC k 0" k 0 = j #-} k x y = x + 2 * y in ... }}} Now suppose that both j and k appear only as saturated tail calls in the body. Thus we would like to make them both join points. The rule complicates matters, though, as its RHS has an unapplied occurrence of j. //However//, if we were to eta-expand the rule, all would be well: {{{ {-# RULES "SPEC k 0" forall a. k 0 a = j a #-} }}} So conceivably we could notice that a potential join point would have an "undersaturated" rule and account for it. This would mean we could make something that's been specialised a join point, for instance. But local bindings are rarely specialised, and being overly cautious about rules only costs us anything when, for some `j`: * Before specialisation, `j` has non-tail calls, so it can't be a join point. * During specialisation, `j` gets specialised and thus acquires rules. * Sometime afterward, the non-tail calls to `j` disappear (as dead code, say), and so now `j` //could// become a join point. This appears to be very rare in practice. TODO Perhaps we should gather statistics to be sure. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13223: Core Prep sometimes generates case of type lambda
by GHC 02 Feb '17

02 Feb '17

#13223: Core Prep sometimes generates case of type lambda -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | 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: -------------------------------------+------------------------------------- Found something odd when updating the test case for T13156: Core Prep will turn {{{ let f = \@a -> case ... in case f @ Any of ... }}} into {{{ case (\@a -> case ...) of f { __DEFAULT -> case f @ Any of ... }}} because `f` is demanded and not an HNF. Seems like this is turning a lazy binding into a strict one since that \@a is about to be erased, but I haven't investigated. (Assigning to myself to put together a proper test case at least.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I'm sorry, I falsely implied the context of this thread. I think the general idea is described in https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes. I noticed the conversation here got stalled so I picked up and experimented where osa1 left: https://ghc.haskell.org/trac/ghc/ticket/1311#comment:12 describes a construct like the following: {{{ type Unlifted = TYPE 'UnliftedRep newtype Blah :: TYPE 'IntRep where Blah :: Int# -> Blah data T :: Unlifted where T :: Int -> Int -> T }}} Which allows: 1. newtype declaration over unlifted types 2. data declarations which are represented through an unlifted pointer (do not contain bottom) The approach mentioned on `UnliftedDataTypes` page introduces a new keyword `unlifted`. This approach differs in that we give the unlifted representation through an explicit kind signature on the newtype/data type instead of a new syntax. And that is what the patch allows in https://ghc.haskell.org/trac/ghc/ticket/1311#comment:18 enables us to write. I can formulate a proposal next week. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I would really like a wiki page to describe the design, please. Maybe it's a simple page -- if so, so much the better. Alex, it's great that you have made a patch but I can't even begin to look at it until I know precisely what it is intended to achieve. Specification before implementation. You might also (perhaps in parallel) want to formulate a [https://github.com/ghc-proposals/ghc-proposals GHC Proposal]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 02 Feb '17

02 Feb '17

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints 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 simonpj): > The second argument is still boxed Even with -O2 (which does a second demand/absence analysis pass? I think, though I have not dug into it, that the absence may only show up late. Even if that's true, we should just check to ensure that there's no way it could have been caught in the first pass. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12988: Join points
by GHC 02 Feb '17

02 Feb '17

#12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature | Status: new request | 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): D2853 | Wiki Page: SequentCore -------------------------------------+------------------------------------- Master ticket for the `wip/join-points` branch. For details, see SequentCore. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 02 Feb '17

02 Feb '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): I have put together a proof of concept [https://github.com/alexbiehl/ghc/commit/57a1a3506c90f2b8f75014ca71ca6b67306… here]. It supports newtypes over unlifted data *and* unlifted data types (with unpacking). This is done without much knowledge about what is a right or wrong thing to do. But I would be happy if we could discuss it and maybe make it a patch we all agree with. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0