April 2017 - ghc-tickets

[GHC] #13419: Testing.
by GHC 11 Apr '17

11 Apr '17

#13419: Testing. -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This is only a test. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13419> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 11 Apr '17

11 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I mean can we change ByteArray# 's representation into just length and content (removing the header)? I don't believe this is possible; as you point out, the garbage collecting needs the info table pointer. > It seems to me we want a way to write a `ByteArray#` literal, without forcing every string literal to be compiled to a `ByteArray#`. I agree; I can see the value in wanting a `ByteArray#` literal, but making all primitive strings `ByteArray#`s seems like a step too far. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13523: Be more explicit in generated case alternatives
by GHC 11 Apr '17

11 Apr '17

#13523: Be more explicit in generated case alternatives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- This came up during the GHC call while discussing #13397 and I thought it would be good to record. Often in the compiler we end up with a case analysis with a number of alternatives and a `DEFAULT` case in place of the remaining alternative, {{{!#hs case x of True -> a DEFAULT -> b }}} Arguably we should instead generate, {{{ case x of True -> a False -> b }}} instead as this may allow the code generator may be able to emit better code when it knows the finite bounds of the switch (e.g. using a jump table). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 11 Apr '17

11 Apr '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It seems to me we want a way to write a `ByteArray#` literal, without forcing every string literal to be compiled to a `ByteArray#`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:68> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust
by GHC 11 Apr '17

11 Apr '17

#4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.2 Resolution: | Keywords: CodeGen 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: => CodeGen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4121#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2731: Avoid unnecessary evaluation when unpacking constructors
by GHC 11 Apr '17

11 Apr '17

#2731: Avoid unnecessary evaluation when unpacking constructors -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: CodeGen 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 simonpj): * keywords: => CodeGen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2731#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11372: Loopification does not trigger for IO even if it could
by GHC 11 Apr '17

11 Apr '17

#11372: Loopification does not trigger for IO even if it could -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm, | Operating System: Unknown/Multiple loopification, code generation | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The loopification optimization, as I understand it, allows a self- recursive function to jump to a local label instead of the beginning of the function, thus skipping a potential stack check. However, I only observe it triggering for pure functions while IO functions do not get that benefit, even when it would be possible. I discovered this in #8793 after looking into an unexpected speedup by removing the IO context from an otherwise pure loop and while such a loop can simply be changed to a pure version (the {{{IOLoop}}} examples), other functions can not, but the optimization could be applied to them (see {{{MapM.hs}}}). I tried to benchmark the differences between a naive loop in IO and some horrible {{{inlinePerformIO}}} hacks to get the loopification to fire and the "optimized" version performs 3-5% faster on my machine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11372> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8585: Loopification should omit stack check
by GHC 11 Apr '17

11 Apr '17

#8585: Loopification should omit stack check ------------------------------+-------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- When we optimize a self-recursive tail call using loopification we don't need to perform a stack check in every loop. This is because a tail recursive function uses constant amount of stack. We should therefore place the loop header after the stack check, but before the heap check (because heap may grow in every call). parcs proposed a patch [https://ghc.haskell.org/trac/ghc/ticket/8275#comment:34 here]. We just need to make sure why it works and add some documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8585> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm
by GHC 11 Apr '17

11 Apr '17

#8871: No-op assignment I64[BaseReg + 784] = I64[BaseReg + 784]; is generated into optimized Cmm ------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello, on SPARC and I also guess on PPC it's possible to get following line in optimized Cmm code: {{{ I64[BaseReg + 784] = I64[BaseReg + 784]; }}} this line is then translated by NCG wasting 5 isns on SPARC at least. Don't know PPC. I'm not sure if this is possible to duplicate this on i386 due to fewer regs. Generally speaking you need to have 32bit target with more regs available. Interesting fact is that such line is not presented in non-optimized Cmm, but is presented in optimized one. Both optimized and non-optimized Cmms attached. Both get from compiling T7507 testcase by stage1 compiler on SPARC: {{{ /home/karel/vcs/ghc-src/ghc-sparc-reg_ncg/inplace/bin/ghc-stage1 -fforce- recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7507.hs -O -ddump-opt-cmm > T7507.opt-cmm- sparc-reg-ncg }}} Of course non-opt Cmm is got by -ddump-cmm instead of -ddump-opt-cmm. If you need more simplified testcase, then following code is usable too: {{{ module Main where import Data.Int main = print ( ( 2 ^ 6 ) :: Int64 ) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8871> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8887: Double double assignment in optimized Cmm on SPARC
by GHC 11 Apr '17

11 Apr '17

#8887: Double double assignment in optimized Cmm on SPARC ----------------------------+-------------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Runtime performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------+-------------------------------------------- Hello, while reading ffi003 asm/opt-cmm for fixing this on SPARC I've noticed this code, this is optimized Cmm dump: {{{ 112 c1or: 113 _s1nw::F64 = F64[_s1nv::P32 + 3]; 114 _c1oj::I32 = sin; 115 _c1ok::F64 = _s1nw::F64; }}} this assignment to _s1nw::F64 looks useless as we may assign directly to _c1ok::F64, may we not? Both optimized and non-optimized Cmms attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3