November 2015 - ghc-tickets

[GHC] #10062: Codegen on sequential FFI calls is not very good
by GHC 05 Sep '16

05 Sep '16

#10062: Codegen on sequential FFI calls is not very good -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm writing a library for efficiently building up a byte buffer. The fastest approach I've found is via FFI, with restricted effects like ST. It's over twice as fast as ByteString Builder. Consider this example API usage: https://github.com/chadaustin/buffer- builder/blob/6bd0a39c56f63ab751faf29f9784ac87d52638be/bench/Bench.hs#L46 It compiles into an instruction sequence containing direct, sequenced FFI calls. For example, the last three calls work out to: addq $8,%rsp movq %rbx,%rdi movq 72(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz addq $8,%rsp movq %rbx,%rdi movl $35,%esi subq $8,%rsp movl $0,%eax call bw_append_byte addq $8,%rsp movq %rbx,%rdi movq 64(%rsp),%rax movq %rax,%rsi subq $8,%rsp movl $0,%eax call bw_append_bsz I don't know why rsp is being changed so much. I also can't explain the assignment to eax before the call. (It should also be xorl eax,eax, I would think.) To my reading, the above instruction sequence could be reduced to: movq %rbx,%rdi movq 64(%rsp),%rsi call bw_append_bsz movq %rbx,%rdi movl $35,%esi call bw_append_byte movq %rbx,%rdi movq 56(%rsp),%rsi call bw_append_bsz To reproduce, check out git@github.com:chadaustin/buffer-builder.git at revision 6bd0a39c56f63ab751faf29f9784ac87d52638be cabal configure --enable-benchmarks cabal bench And then look at the ./dist/build/bench/bench-tmp/bench/Bench.dump-asm file. This is specifically on OS X 64-bit with GHC 7.8.3, but I saw similar code generation on GHC 7.6 on Linux 64-bit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10858: Smaller generated instances
by GHC 05 Sep '16

05 Sep '16

#10858: Smaller generated instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- With very large modules with lots of deriving code, GHC spends quite some time compiling. I believe that we can improve things by reducing the size of the generated code. (More in the comments) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10161: GHC does not relink if a library's code changed
by GHC 03 Sep '16

03 Sep '16

#10161: GHC does not relink if a library's code changed -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Test case for reproducing: https://github.com/nh2/ghc-relinking-avoidance- bug/ ---- {{{myexe}}} is an executable that depends on {{{mylib}}}, whose {{{myfun = putStrLn "output 1"}}}. If we install {{{mylib}}}, compile {{{myexe}}}, then change mylib's code to {{{myfun = putStrLn "output 2"}}}, re-install it, and then compile {{{myexe}}}, then GHC does not notice that the library code changed. It avoids re-linking myexe, with the result that the program prints {{{output 1}}} when you told it to compile against code that prints {{{output 2}}}. ---- Note that I had to use {{{NOINLINE myfun}}} to trigger the bug, since otherwise {{{myfun}}}'s code would have ended up in the interface file, thus changing the package ID, which naturally forces GHC to relink (even re-compile). With the {{{NOINLINE}}}, the package IDs of the two different versions of {{{myfun}}} are completely identical. I think that is correct, since the package ID only hashes the API and ABI, not the actual implementation, right? How does GHC decide when to relink? I think in the present case, it doesn't notice that the object/archive file of the library changed. Does it check that somehow? Just looking at API and API can't be enough to make a decision for linking. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10923: GHC should recompile if flags change
by GHC 02 Sep '16

02 Sep '16

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Example: {{{ ezyang@sabre:~$ rm B.hi ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs -O compilation IS NOT required }}} Pretty minor, but would be nice to have fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10923> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10963: Beginner-targeted language extension
by GHC 29 Aug '16

29 Aug '16

#10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- FMP significantly complicated type signatures such as `length :: Foldable t => t a -> Int`, which makes teaching Haskell more difficult. I propose a language extension `-XBeginner` which instructs GHC(i) to specialize `Foldable` and `Traversable` to `[]` when possible and in case of an ambiguous instance, default those to `[]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #10547: feature request: expanding type synonyms in error messages
by GHC 26 Aug '16

26 Aug '16

#10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type errors sometimes becoming confusing because of synonyms, for example, expected type and found type sometimes use different synonyms or sometimes only one of them use a synonym etc. We discussed this in the mailing list: https://mail.haskell.org/pipermail /ghc-devs/2015-June/009247.html And also moved it to the Wiki to collect examples: https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal I'm currently working on a patch, I made some progress and I'll hopefully submit something for reviews in a couple of days. This ticket is for further discussions and keep track of the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows
by GHC 25 Aug '16

25 Aug '16

#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is adapted from the comments [https://github.com/bos/text- icu/issues/12#issuecomment-154452774 here].) On Windows, the GHC runtime linker only searches for DLLs that have the same names as the import libraries passed to `-l`. This can sometimes create problems, since a library name could be different from the DLL it needs. `text-icu` provides an example of this, since it needs the extra libraries `icuuc`, `icudt`, and `icuin`. However, if you download the [http://site .icu-project.org/download/56#TOC-ICU4C-Download official ICU 56 binaries], they are distributed with DLLs named `icuuc56.dll`, `icudt56.dll`, and `icuin56.dll`, rather than `icuuc.dll`, `icudt.dll`, and `icuin.dll`. This doesn't create any trouble for the linker at compile-time. In fact, if you compile this program {{{#!hs -- TextICU.hs import Data.Text.ICU.Break main = print Kana }}} with `ghc TextICU.hs` and then run `cygcheck ./TextICU.hs` without having the ICU4C `bin64` folder in your `PATH`, it ''appears'' to search for the right DLLs: {{{ $ cygcheck ./TextICU.hs ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll }}} But actually running the code reveals a different story: {{{ $ runghc TextICU.hs TextICU.hs: icuuc: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc.dll (addDLL: could not load DLL) }}} This demonstrates that the runtime linker behaves differently; it is dependent on what the linked libraries' names are. To confirm this, you can recompile `text-icu` with the following changes to `text-icu.cabal`: {{{ extra-libraries: icuuc56 if os(mingw32) extra-libraries: icuin56 icudt56 }}} Also make symlinks named `icuuc56.lib`, `icuin56.lib`, and `icudt56.lib` that refer to `icuuc.lib`, `icuin.lib`, and `licudt.lib`, respectively, in the ICU4C `lib64` directory. Now `cygcheck` and `ghc` agree on which DLLs to use: {{{ $ ghc TextICU.hs $ cygcheck ./TextICU.exe ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll $ runghc TextICU.hs TextICU.hs: icuuc56: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc56.dll (addDLL: could not load DLL) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11068: Make Generic/Generic1 methods inlinable
by GHC 23 Aug '16

23 Aug '16

#11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D1447 | Wiki Page: -------------------------------------+------------------------------------- Efficient code generation with GHC.Generics relies on the optimizer being able to completely remove the generic representation of a type. Marking these methods as inlinable ensures that this will be possible even for larger types. I'm working on techniques for transforming generically derived lenses and traversals which rely on taking advantage of the Functor and Applicative laws. This patch supports that work. https://github.com/glguy/generic-traverse -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8955: Syscall intrinsic
by GHC 18 Aug '16

18 Aug '16

#8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9498: GHC links against unversioned .so files
by GHC 16 Aug '16

16 Aug '16

#9498: GHC links against unversioned .so files ------------------------------------+-------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (FFI) | Version: 7.6.3 Keywords: Debian | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+-------------------------------- Greetings, GHC tries to load unversioned dynamic libraries instead of versioned (i.e. libfoo.so instead of libfoo.so.1.2.3). This is a problem, since Distributions like Debian (I don't know about other distributions) don't include unversioned .SOs in their runtime packages and the unversioned are only available in the -dev packages as a symlink to the verioned ones. This means FFI libraries depend on the -dev packages, even though they don't really need them. It would be nice if GHC would try to load the versioned libraries as well. Regards Sven -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26