February 2016 - ghc-tickets

Re: [GHC] #2289: Needless reboxing of values when returning from a tight loop
by GHC 20 Feb '16

20 Feb '16

#2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by twhitehead): I was just going to open a ticket to report that I had discovered that the compiler can't unbox multiple return values. That is, anytime you create a non-inlined function (such as a loop) that returns multiple values, you must pay the boxing and unboxing penalty. My reading of these tickets (#1600, #2289, and #2387) though is that this is already known. I'll just add a simple example here {{{ #!haskell main :: IO () main = case loop2 100 (10,10) of (au,ad) -> print (au - ad) loop2 :: Int -> (Int,Int) -> (Int,Int) loop2 n (au,ad) | n > 0 = loop2 (n-1) (au+1,ad-1) | otherwise = (au,ad) }}} yielding (with ''-ddump-simpl -dsuppress-all -dno-suppress-type- signatures'') {{{ #!haskell Rec { main_$s$wloop2 [Occ=LoopBreaker] :: Int# -> Int# -> Int# -> (# Int, Int #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType <L,U><L,U><L,U>] main_$s$wloop2 = \ (sc_s3vn :: Int#) (sc1_s3vo :: Int#) (sc2_s3vp :: Int#) -> case tagToEnum# (># sc_s3vn 0) of _ [Occ=Dead] { False -> (# I# sc1_s3vo, I# sc2_s3vp #); True -> main_$s$wloop2 (-# sc_s3vn 1) (+# sc1_s3vo 1) (-# sc2_s3vp 1) } end Rec } main1 :: State# RealWorld -> (# State# RealWorld, () #) [GblId, Arity=1, Str=DmdType <L,U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 171 0}] main1 = \ (eta_B1 [OS=OneShot] :: State# RealWorld) -> case main_$s$wloop2 100 10 10 of _ [Occ=Dead] { (# ww1_s3uF, ww2_s3uG #) -> hPutStr2 stdout (case ww1_s3uF of _ [Occ=Dead] { I# x_a1d4 -> case ww2_s3uG of _ [Occ=Dead] { I# y_a1d8 -> case $wshowSignedInt 0 (-# x_a1d4 y_a1d8) ([]) of _ [Occ=Dead] { (# ww5_a1xQ, ww6_a1xR #) -> : ww5_a1xQ ww6_a1xR } } }) True eta_B1 } }}} Cheers! -Tyson PS: The perfect performance storm comes when you have a very fast inner loop returning multiple values to an outer loop that evaluates the inner loop many many times. * The inner loop can't be inlined because it is a loop. * The return values from the inner loop must be boxed and unboxed because GHC doesn't seem to be able to do otherwise when there are multiple return values. * The inner loop being very fast means the relative cost of boxing and unboxing is high. * The outer loop repeating the inner loop many many times turns the high relative cost into a high absolute cost. In my specific case I was processing around 10G worth of text records. The inner loop found the next field separator. The outer loop built the data records. It was a nasty hit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2289#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7337: GHC does not generate great code for bit-level rotation
by GHC 19 Feb '16

19 Feb '16

#7337: GHC does not generate great code for bit-level rotation -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.1 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 jberryman): For my uses (also hashing) a `uncheckedRotateL# :: Word# -> Int# -> Word#` would be sufficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7337#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10196: Regression regarding Unicode subscript characters in identifiers
by GHC 19 Feb '16

19 Feb '16

#10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #5108 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As reported by both hvr as user Yongqian Li: The Unicode7 update in GHC 7.10 had the side effect of breaking code making use of subscript symbols that did compile with GHC 7.8.4, but won't anymore with GHC 7.10.1: For instance, GHCi 7.8.4 accepts let xᵦ = 1 let xᵤ = 1 let xᵩ = 1 let xᵢ = 1 let xᵪ = 1 let xᵣ = 1 let xₙ = 1 whereas GHC 7.10.1RC fails parsing those with a lexical error. (NB: GHC 7.8 does not accept *all* latin subscript letters either). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #11191: provide `make uninstall`
by GHC 19 Feb '16

19 Feb '16

#11191: provide `make uninstall` -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: installation | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As now there is no `make uninstall` for GHC. Even though most of the times this is not strictly needed, there are cases where this would be useful (a system with not much disk space available). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #1831: reify never provides the declaration of variables
by GHC 19 Feb '16

19 Feb '16

#1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.1 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: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1831#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections
by GHC 19 Feb '16

19 Feb '16

#7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: Doesn't seem like a popular task. Removing keyword to keep the newcomers list fresh. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7670#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1262: RecursiveDo in Template Haskell
by GHC 19 Feb '16

19 Feb '16

#1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@… | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.6 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: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: No takers. Removing keyword to keep the newcomers list fresh. Please put it back if you disagree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1262#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9993: PostfixOperators doesn't work for types
by GHC 19 Feb '16

19 Feb '16

#9993: PostfixOperators doesn't work for types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `PostfixOperators` is a useful extension on the value level that defines `(x OP)` to mean `((OP) x)` for an infix operator `OP`, rather than `(\y -> (OP) x y)`. This could be even more useful on the type level, where lambdas are unavailable (so sections don't exist at all) but postfix operators could still exist. This is already a common pseudocode idiom in some cases, e.g. `(r ->)` instead of `((->) r)`. Is there a particular syntactic reason to disallow it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors.
by GHC 19 Feb '16

19 Feb '16

#2742: The -> in ViewPatterns binds more weakly than infix data constructors. -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 (Parser) | 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: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: nomeata: I'm removing the newcomer keyword from this ticket, as it didn't see any takers in 15 months. It might be too difficult or uninteresting, but please put the keyword back if you disagree. By keeping the newcomers list fresh, I hope we will see newcomer activity pick up a little. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2742#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9518: Improve error message for unacceptable role annotations
by GHC 19 Feb '16

19 Feb '16

#9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice if this message: {{{ Role mismatch on variable a: Annotation says representational but role nominal is required while checking a role annotation for `Point' }}} Could be extended to say where the requirement arises. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5