January 2017 - ghc-tickets

[GHC] #13160: Simplify CoreFV.FVAnn
by GHC 12 Apr '17

12 Apr '17

#13160: Simplify CoreFV.FVAnn -------------------------------------+------------------------------------- Reporter: simonpj | Owner: 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: -------------------------------------+------------------------------------- When introducing type-in-type, Richard elaborated the free varaible finder so that it finds three things at once (in `CoreFV`): {{{ data FVAnn = FVAnn { fva_fvs :: DVarSet -- free in expression , fva_ty_fvs :: DVarSet -- free only in expression's type , fva_ty :: Type -- expression's type } }}} I think `fva_ty` is needed only to support `fva_ty_fvs`. And `fva_ty_fvs` seems to be used only to support the calls to `freeVarsOfType` in `FloatIn`. And those calls in turn are only to suppor `used_in_ty` in `FloatIn.sepBindsByDropPoint`. In conversation yesterday, Richard and I agreed that all this is unnecessary. Coercion bindings simply do not float inwards, so we do not need to take these precautions. (We should add a Note to explain why they don't float, and what problem might arise if they did.) To confirm this I set `used_in_ty` to `False` and compiled from scratch; everything is fine. So I propose that we * get rid of the `ty_fvs` argument to `sepBindsByDropPoint` * simplfy `FVAnn` to just gather free variables (ie one field only) Result: it's all simpler. Richard will do this when he gets a moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13138: Clean up ghc-pkg validation warnings in build log
by GHC 12 Apr '17

12 Apr '17

#13138: Clean up ghc-pkg validation warnings in build log -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | 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: -------------------------------------+------------------------------------- The build log has hundreds of lines of `ghc-pkg` warnings which I imagine are due to how GHC's build system is different to normal. We should either work out why there are so many errors and fix them or if they are harmless suppress them to remove the noise from the log. {{{ binary-0.8.3.0: Warning: Unrecognized field abi-depends on line 40 27 binary-0.8.3.0: Warning: Unrecognized field abi on line 28 28 binary-0.8.3.0: Warning: Unrecognized field indefinite on line 22 29 binary-0.8.3.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/binary/dist-boot/doc/html/binary/binary.haddock doesn't exist or isn't a file 30 binary-0.8.3.0: cannot find any of ["Data/Binary.hi","Data/Binary.p_hi","Data/Binary.dyn_hi"] (ignoring) 31 binary-0.8.3.0: cannot find any of ["Data/Binary/Builder.hi","Data/Binary/Builder.p_hi","Data/Binary/Builder.dyn_hi"] (ignoring) 32 binary-0.8.3.0: cannot find any of ["Data/Binary/Get.hi","Data/Binary/Get.p_hi","Data/Binary/Get.dyn_hi"] (ignoring) 33 binary-0.8.3.0: cannot find any of ["Data/Binary/Get/Internal.hi","Data/Binary/Get/Internal.p_hi","Data/Binary/Get/Internal.dyn_hi"] (ignoring) 34 binary-0.8.3.0: cannot find any of ["Data/Binary/Put.hi","Data/Binary/Put.p_hi","Data/Binary/Put.dyn_hi"] (ignoring) 35 binary-0.8.3.0: cannot find any of ["Data/Binary/Class.hi","Data/Binary/Class.p_hi","Data/Binary/Class.dyn_hi"] (ignoring) 36 binary-0.8.3.0: cannot find any of ["Data/Binary/Internal.hi","Data/Binary/Internal.p_hi","Data/Binary/Internal.dyn_hi"] (ignoring) 37 binary-0.8.3.0: cannot find any of ["Data/Binary/Generic.hi","Data/Binary/Generic.p_hi","Data/Binary/Generic.dyn_hi"] (ignoring) 38 binary-0.8.3.0: cannot find any of ["libHSbinary-0.8.3.0.a","libHSbinary-0.8.3.0.p_a","libHSbinary-0.8.3.0-ghc7.10.3.so","libHSbinary-0.8.3.0-ghc7.10.3.dylib","HSbinary-0.8.3.0-ghc7.10.3.dll"] on library path (ignoring) 39 Cabal-1.25.0.0: Warning: Unrecognized field abi-depends on line 125 40 Cabal-1.25.0.0: Warning: Unrecognized field abi on line 106 41 Cabal-1.25.0.0: Warning: Unrecognized field indefinite on line 20 42 Cabal-1.25.0.0: Warning: haddock-interfaces: /var/drydock/workingcopy-21831/repo/glasgow-haskell- compiler/libraries/Cabal/Cabal/dist-boot/doc/html/Cabal/Cabal.haddock doesn't exist or isn't a file 43 Cabal-1.25.0.0: cannot find any of ["Distribution/Backpack.hi","Distribution/Backpack.p_hi","Distribution/Backpack.dyn_hi"] (ignoring) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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

[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] #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

[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