April 2014 - ghc-tickets

[GHC] #8082: Ordering of assembly blocks affects performance
by GHC 10 May '17

10 May '17

#8082: Ordering of assembly blocks affects performance ----------------------------------+--------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- During my work on #6135 I noticed that performance of reverse-complem benchmark in nofib depends highly on the order in which assembly block are laid out. With my patches I am consistently getting a 18-20% speed-up. In theory my patches should not impact performance of existing programs, but for some reason they affect the ordering of generated assembly blocks. On of the earlier versions of my patch I noticed that kahan benchmark suffered a 16% performance hit and again the only difference I noticed in the generated assembly was ordering of blocks. I did a more in-depth investigation in case of kahan and it turned out that this difference results from the way Core is generated: the difference between HEAD and my patches was that a worker function had its three parameters passed in different order. I did not investigate this for reverse-complem because Core is considerably larger, but I could spend some time on it if it might be relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8332: hp2ps does not escape parentheses
by GHC 09 May '17

09 May '17

#8332: hp2ps does not escape parentheses ------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If some symbol name in the key includes a (, but is cut off before the ), hp2ps generates an invalid postscript file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code
by GHC 07 May '17

07 May '17

#8101: No pattern match non-exhaustiveness warnings when compiling with -fno-code -------------------------+------------------------------------------------- Reporter: exbb2 | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.6.3 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ {-# OPTIONS_GHC -Wall #-} module A where data ABC = A | B | C abc :: ABC -> Int abc x = case x of A -> 1 }}} {{{ $ ghc -fno-code -fforce-recomp /tmp/A.hs [1 of 1] Compiling A ( /tmp/A.hs, nothing ) }}} {{{ $ ghc -fobject-code -fforce-recomp /tmp/A.hs [1 of 1] Compiling A ( /tmp/A.hs, /tmp/A.o ) /tmp/A.hs:7:9: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: B C }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8443: cannot find normal object file when compiling TH code
by GHC 01 May '17

01 May '17

#8443: cannot find normal object file when compiling TH code ----------------------------+---------------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Unfortunately, I haven't been able to whittle this down to a smaller test case. In order to reproduce, just run `cabal install yesod-core-1.2.4.5 --enable-tests`. The result is: {{{ test/YesodCoreTest/NoOverloadedStrings.hs:16:26: cannot find normal object file ‛dist/build/tests/tests- tmp/YesodCoreTest/NoOverloadedStringsSub.dyn_o’ while linking an interpreted expression }}} Tested using: The Glorious Glasgow Haskell Compilation System, version 7.7.20131012 cabal-install version 1.18.0.2 using version 1.18.0 of the Cabal library I'm on Ubuntu 12.04 64-bit. Compiling with GHC 7.6.3 and 7.4.2 works correctly. Let me know if there's any other information I can provide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8996: mark more things as const in C codegen
by GHC 24 Apr '17

24 Apr '17

#8996: mark more things as const in C codegen -------------------------------------------+------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Recently i've tried to build ghc-7.8.2 on ia64 and it overflows so called "short data" section. (it's where global 'static' variables live). I've looked at low-hanging fruits of squashing such global "variables". One source of them seems to be a string literal. Consider one-line module: {{{ module B (v) where v = "hello" }}} in '''-fvia-C''' (or unreg) mode it generates code like {{{ static char gibberish_str[] = "hello"; }}} It uselessly eats data section. The patch switches generator to emit: {{{ static const char gibberish_str[] = "hello"; }}} Some notes: 1. as far as I see native codegens already put ot to .rodata, thus it should be safe. 2. I likely didn't cover more cases, like - RelocatableReadOnlyData - and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))''' Size of unreg-stage2 on amd64 before and after the patch: {{{ $ size inplace/lib/bin/ghc-stage2 (unpatched) text data bss dec hex filename 81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2 $ size inplace/lib/bin/ghc-stage2 (patched) text data bss dec hex filename 83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2 }}} Text section increased for 1.6MBs (consts moved here, likely .rodata actually), data section decreased for 1.7MBs. I think with minor fiddling with linker flags we can merge equal constants later on. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8808: ImpredicativeTypes type checking fails depending on syntax of arguments
by GHC 24 Apr '17

24 Apr '17

#8808: ImpredicativeTypes type checking fails depending on syntax of arguments -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1-rc1 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- g1 and g2 below type check, but g1', g2', and g2'' don't even though the types are exactly the same. {{{ {-# LANGUAGE ImpredicativeTypes, NoMonomorphismRestriction #-} module Test where f1 :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char]) f1 (Just g) = Just (g [3], g "hello") f1 Nothing = Nothing f2 :: [forall a. [a] -> [a]] -> Maybe ([Int], [Char]) f2 [g] = Just (g [3], g "hello") f2 [] = Nothing g1 = (f1 . Just) reverse g1' = f1 (Just reverse) g2 = f2 [reverse] g2' = f2 ((:[]) reverse) g2'' = f2 (reverse : []) }}} Compiling it with HEAD gives these errors: {{{ [1 of 1] Compiling Test ( test.hs, test.o ) test.hs:12:16: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a2] -> [a2]’ In the first argument of ‛Just’, namely ‛reverse’ In the first argument of ‛f1’, namely ‛(Just reverse)’ test.hs:15:17: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a0] -> [a0]’ In the first argument of ‛: []’, namely ‛reverse’ In the first argument of ‛f2’, namely ‛((: []) reverse)’ test.hs:16:12: Couldn't match expected type ‛forall a. [a] -> [a]’ with actual type ‛[a1] -> [a1]’ In the first argument of ‛(:)’, namely ‛reverse’ In the first argument of ‛f2’, namely ‛(reverse : [])’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8426: one-shot compilation + TH doesn't see instances that is seen in batch mode
by GHC 15 Apr '17

15 Apr '17

#8426: one-shot compilation + TH doesn't see instances that is seen in batch mode ----------------------------------------------+---------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Other Blocked By: | Test Case: Related Tickets: #7867 | Blocking: ----------------------------------------------+---------------------------- Haskell prime and Haskell98 both states that instances are always seen if there is any chain of imports leading from the current module to the instance. http://darcs.haskell.org/haskell-prime-report/report/haskell-report- html/modules.html#import-instances The ghc manual contains a discussion why this specification is too performance heavy to näively implement and contains the definition of orphanness and an algorithm to reproduce the specification with better performance. http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/separate- compilation.html#orphan-modules Unfortunately this cleverness breaks template haskell. Namely, if: - `Class.hs` contains a class, - `NonOrphan.hs` contains a data that implements the class, - `Importer.hs` just imports `NonOrphan.hs`, - `Main.hs` imports `Importer.hs`, - `Main.hs` reifies the class; then: - one-shot compilation's reify doesn't see the instance, - batch compilation's reify sees the instance. This ambiguity is shown in the attached tgz. Furthermore if `NonOrphan.hs` is in a separate package, then of course even batch compilation mode wouldn't reify the instance correctly. In that case there is no disambiguity between one-shot and batch, simply both is missing the info. I propose to solve this by enforcing a loading of all the interface files for every import transitively for the current module, when we meet an open type family or class reification request in template haskell's reify handler in `TcSplice.hs`. So I propose to keep the optimization of orphan instances and use it 99.9% of the time. We would only ever go on the quest of reading interface files for every import transitively when the user tries to reify something where we have to return an instance list. This means that TH compilations that reify types will get a little bit slower in exchange of being correct and unambiguous. Compilation time in cases when TH reification is not used will not change. I volunteer to prepare the patch, but would like to hear others first. So, any opinions, alternative ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8426> 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