April 2017 - ghc-tickets

[GHC] #9159: cmm case, binary search instead of jump table
by GHC 11 Apr '17

11 Apr '17

#9159: cmm case, binary search instead of jump table ------------------------------+-------------------------------------------- Reporter: wojteknar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I'm not sure if this is qualifies as a bug or feature request. For case expressions where the scrutinee is Int#,or Int, or probably anything else numerical, GHC generates binary search, where a jump table could easily be used instead. The functions toChunk1# and toChunk2# yield suboptimal code. I found a satisfactory workaround, toChunk3# uses Enum and it is fine. For the attached code it probably does not matter much, but I have 65 cases in my real code, trying to implement a variant of ByteString, which will have the lowest possible storage overhead (just the info table pointer == one word) for lengths up to 64 bytes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13563: Avoid redundant MOVes in generated code
by GHC 11 Apr '17

11 Apr '17

#13563: Avoid redundant MOVes in generated code --------------------------------------+--------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I stumbled upon this generated code: Everything is fine, a heap check like many others. {{{#!hs c2ro: Hp = Hp + 16; if (Hp > I64[BaseReg + 856]) goto c2rt; else goto c2rs; c2rt: I64[BaseReg + 904] = 16; I64[Sp - 48] = block_c2rp_info; I64[Sp - 40] = _s2pI::I64; I64[Sp - 32] = _s2pJ::I64; I64[Sp - 24] = _s2pK::I64; I64[Sp - 16] = _s2pN::I64; I64[Sp - 8] = _s2pO::I64; Sp = Sp - 48; call stg_gc_noregs() returns to c2rp, args: 8, res: 8, upd: 8; c2rp: _s2pI::I64 = I64[Sp + 8]; _s2pJ::I64 = I64[Sp + 16]; _s2pK::I64 = I64[Sp + 24]; _s2pN::I64 = I64[Sp + 32]; _s2pO::I64 = I64[Sp + 40]; Sp = Sp + 48; goto c2ro; c2rs: }}} Compiled to assembler: {{{#!asm _c2ro: addq $16,%r12 ; Heap check as usual cmpq 856(%r13),%r12 ja _c2rt _c2rs: ... _c2rt: movq $16,904(%r13) movq $block_c2rp_info,-48(%rbp) movq %r14,-40(%rbp) ; copy out sequence: move live variables movq %rsi,-32(%rbp) ; to stack movq %rax,-24(%rbp) movq %rbx,-16(%rbp) movq %rdi,-8(%rbp) addq $-48,%rbp jmp stg_gc_noregs ... .align 8 .quad 1989 .quad 32 block_c2rp_info: _c2rp: movq 8(%rbp),%rax ; we returned from gc land, now copy live variables back in movq 16(%rbp),%rbx movq 24(%rbp),%rcx movq 32(%rbp),%rdx movq 40(%rbp),%rsi addq $48,%rbp _n2st: ; Oh dear! We are moving our freshly moved register again for no obvious reason! movq %rsi,%rdi movq %rbx,%rsi movq %rdx,%rbx movq %rax,%r14 movq %rcx,%rax jmp _c2ro }}} What is happening here that GHC isn't able to directly assign the correct registers? Also the label `_n2st` suggest it is inserted at a later stage than the generated cmm code (Every other label is named contigously). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13562: Avoid redundant MOVes in generated code
by GHC 11 Apr '17

11 Apr '17

#13562: Avoid redundant MOVes in generated code --------------------------------------+--------------------------------- Reporter: alexbiehl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I stumbled upon this generated code: Everything is fine, a heap check like many others. {{{#!hs c2ro: Hp = Hp + 16; if (Hp > I64[BaseReg + 856]) goto c2rt; else goto c2rs; c2rt: I64[BaseReg + 904] = 16; I64[Sp - 48] = block_c2rp_info; I64[Sp - 40] = _s2pI::I64; I64[Sp - 32] = _s2pJ::I64; I64[Sp - 24] = _s2pK::I64; I64[Sp - 16] = _s2pN::I64; I64[Sp - 8] = _s2pO::I64; Sp = Sp - 48; call stg_gc_noregs() returns to c2rp, args: 8, res: 8, upd: 8; c2rp: _s2pI::I64 = I64[Sp + 8]; _s2pJ::I64 = I64[Sp + 16]; _s2pK::I64 = I64[Sp + 24]; _s2pN::I64 = I64[Sp + 32]; _s2pO::I64 = I64[Sp + 40]; Sp = Sp + 48; goto c2ro; c2rs: }}} Compiled to assembler: {{{#!asm _c2ro: addq $16,%r12 ; Heap check as usual cmpq 856(%r13),%r12 ja _c2rt _c2rs: ... _c2rt: movq $16,904(%r13) movq $block_c2rp_info,-48(%rbp) movq %r14,-40(%rbp) ; copy out sequence: move live variables movq %rsi,-32(%rbp) ; to stack movq %rax,-24(%rbp) movq %rbx,-16(%rbp) movq %rdi,-8(%rbp) addq $-48,%rbp jmp stg_gc_noregs ... .align 8 .quad 1989 .quad 32 block_c2rp_info: _c2rp: movq 8(%rbp),%rax ; we returned from gc land, now copy live variables back in movq 16(%rbp),%rbx movq 24(%rbp),%rcx movq 32(%rbp),%rdx movq 40(%rbp),%rsi addq $48,%rbp _n2st: ; Oh dear! We are moving our freshly moved register again for no obvious reason! movq %rsi,%rdi movq %rbx,%rsi movq %rdx,%rbx movq %rax,%r14 movq %rcx,%rax jmp _c2ro }}} What is happening here that GHC isn't able to directly assign the correct registers? Also the label `_n2st` suggest it is inserted at a later stage than the generated cmm code (Every other label is named contigously). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13562> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4154: Deadlock in Chan module
by GHC 11 Apr '17

11 Apr '17

#4154: Deadlock in Chan module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > Is it possible to define instead of isEmptyChan some non-blocking version of > readChan with tryTakeMVar and tryPutMVar? I think this can't work. A `readChan` is actually two `takeMVar`s. Implementation of `tryReadChan` has to use `tryTakeMVar`s, otherwise you can't avoid being blocked in some cases. So these two MVars that need to be taken to be able to read something off a chan need to be taken with `tryReadChan`. First `tryTakeMVar` would only succeed if the queue is empty. The trouble is in the case where the chan has enough stuff but currently some other thread is busy actually reading the contents (and updating the read-end) you'd get a `Nothing`, even though if you actually do `readChan` you'd get blocked for a very short amount of time because chan has enough contents. So this implementation would return `Nothing` in some cases when there is enough contents in the chan. Now suppose that you use `tryReadMVar` to read the read-end. Suppose that right after you read the read-end another thread does `readChan`, and takes the read-end MVar. Now there's a race condition between your thread and the other thread. The loser needs to re-take the read-end. Furthermore, if your thread was the only thread you can't update the read-end, because you didn't take it (remember that in this scenario we use `tryReadMVar` instead of `tryTakeMVar`). So neither `tryTakeMVar` nor `tryReadMVar` gives you a race-free implementation of `tryReadChan`. I hope this makes sense. (Another problem with both implementations is that you have no guarantees that you'll be able to read the contents. For example if chan has enough contents but a million threads are running `readChan` in parallel you may not be able to read anything with `tryReadChan`) `MVar`-based implementation is cute but has this limitation. (it also doesn't scale as number of writers and readers increase) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4154#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12603: INLINE and manually inlining produce different code
by GHC 11 Apr '17

11 Apr '17

#12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | 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): | Wiki Page: -------------------------------------+------------------------------------- Mikolaj reported that he was seeing significantly different code generated in the case of a manual `INLINE` versus manually inlining. I haven't looked into what the cause it and this isn't necessarily problematic; this is just a reminder to look into what is happening. See https://github.com/LambdaHack/LambdaHack/blob/97724fe8c73e80b329ddf326a8eb0…. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12603> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

Re: [GHC] #5609: Type checking arrow notation in the presence of deferred constraints
by GHC 11 Apr '17

11 Apr '17

#5609: Type checking arrow notation in the presence of deferred constraints -------------------------------------+------------------------------------- Reporter: dreixel | Owner: ross Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (Type | Version: 7.3 checker) | Resolution: fixed | Keywords: Arrows 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 simonpj): * keywords: => Arrows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5609#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5022: Core Lint error from polymorphic definitions inside arrow rec
by GHC 11 Apr '17

11 Apr '17

#5022: Core Lint error from polymorphic definitions inside arrow rec -----------------------------------+-------------------------------------- Reporter: serpentologist | Owner: ross Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.0.2 Resolution: fixed | Keywords: Arrows Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: arrows/T5022 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by simonpj): * keywords: infinite loop => Arrows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5022#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7071: Refactoring arrows
by GHC 11 Apr '17

11 Apr '17

#7071: Refactoring arrows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: fixed | Keywords: Arrows 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 simonpj): * keywords: => Arrows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7071#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8505: Arrows example error
by GHC 11 Apr '17

11 Apr '17

#8505: Arrows example error ------------------------------------+-------------------------------------- Reporter: pdfrod | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- In the section '''7.15.2. Conditional commands''' of the User's Guide (http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/arrow- notation.html#idp49515792) it is stated that: {{{ proc (x,y) -> if f x y then g -< x+1 else h -< y+2 }}} is translated to: {{{ arr (\ (x,y) -> if f x y then Left x else Right y) >>> (arr (\x -> x+1) >>> f) ||| (arr (\y -> y+2) >>> g) }}} But this translation doesn't seem correct, because the arrows ''g'' and ''h'' are not being used as in the original code (''h'' doesn't appear at all in the translation). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10582: Tiny bug in lexer around lexing banana brackets
by GHC 11 Apr '17

11 Apr '17

#10582: Tiny bug in lexer around lexing banana brackets -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.10.3 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ {-# LANGUAGE Arrows #-} (|:) :: Int -> Int -> Int (|:) = (+) }}} I get {{{ /Users/rae/temp/Bug.hs:3:3: parse error on input ‘:’ }}} Trying this with other operators, like `(|+)`, works fine. The problem is that `notFollowedBySymbol` in Lexer.x is slightly wrong. I will fix in ongoing (mostly unrelated) work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10582> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4