August 2018 - ghc-tickets

[GHC] #12232: Opportunity to do better in register allocations
by GHC 26 Nov '18

26 Nov '18

#12232: Opportunity to do better in register allocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #12231 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://github.com/harendra-kumar/unicode-transforms/tree/GHC_PERF_ISSUE This github repo] demonstrates that introduction of one "if" condition which is never taken, degrades the performance of the fast path loop in this particular use case by around 70%, from 2.6ms to 4.4 ms. On investigation I found two main issues. See #12231(ticket) regarding rdeundant allocations. This one is about the other issue regarding register allocations. [https://github.com/harendra-kumar/unicode- transforms/commit/261dbb35e753376e4ee160dab556051738a0be50#diff- 4be4240cb00d1b13a038d1d45fbae235 See this assembly diff] of instructions executed in both cases. The repo has both versions to play with and simpl/stg/cmm/asm are checked in. The first file in the diff is with the if condition and the second one without. To summarize, the introduction of "if" condition adds the following register manipulations before and after the main logic: {{{ # reassignments # rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx => 0x408d7e: mov %rbx,0x90(%rsp) => 0x408d86: mov %rcx,%rbx => 0x408d89: mov %rdx,%rcx => 0x408d8c: mov %rsi,%rdx => 0x408d8f: mov %rdi,%rsi => 0x408d92: mov %r8,%rdi => 0x408d95: mov %r9,%r8 => 0x408d98: mov %r10,%r9 => 0x408d9b: mov 0x90(%rsp),%r10 . . . loop logic here which uses only %rax, %r10 and %r9 . . . . # _n4s8: # shuffle back to original assignments => 0x4090dc: mov %r14,%r11 => 0x4090df: mov %r9,%r10 => 0x4090e2: mov %r8,%r9 => 0x4090e5: mov %rdi,%r8 => 0x4090e8: mov %rsi,%rdi => 0x4090eb: mov %rdx,%rsi => 0x4090ee: mov %rcx,%rdx => 0x4090f1: mov %rbx,%rcx => 0x4090f4: mov %rax,%rbx => 0x4090f7: mov 0x88(%rsp),%rax => 0x4090ff: jmpq 0x408d2a }}} The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. My suspicion is that this allocation is being done en bloc keeping several paths in mind, just like the heap allocations I reported in the other issue. Some questions to be answered: * Can we make this smarter? * Will `-fregs-graph` do a better job and if not what improvements can be done to graph coloring allocator to do a good job here? I have try that option yet. LLVM assembly trace is also available in the repo. == References == * [1] mail thread: https://mail.haskell.org/pipermail/ghc- devs/2016-June/012243.html * [2] github code repo: https://github.com/harendra-kumar/unicode- transforms/tree/GHC_PERF_ISSUE -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13262: Allow type synonym family application in instance head if it reduces away
by GHC 26 Nov '18

26 Nov '18

#13262: Allow type synonym family application in instance head if it reduces away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- GHC rejects the following program: {{{ {-# LANGUAGE TypeFamilies, FlexibleInstances #-} module F where type family F a type instance F Int = Int -> Int instance Show (F Int) where show _ = "fun" }}} But this doesn't seem fundamentally problematic to me: at the instance declaration, we know that F Int will reduce, and after that reduction there isn't any problem with the instance. Here's a less restrictive instance head test: first, we reduce type families as much as possible. Then, if there are still leftover non- reducing type families, reject the instance. After having typed this up, I have realized that I don't actually need this feature. But I'm filing it here for posterity. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14690: Pattern match failure in GHCi with :steplocal
by GHC 26 Nov '18

26 Nov '18

#14690: Pattern match failure in GHCi with :steplocal --------------------------------------+--------------------------------- Reporter: Philonous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Using steplocal after breaking on an exception leads to GHCI giving a pattern match error Minimal testcase: {{{ Prelude> :set -fbreak-on-exception Prelude> error "abc" Stopped in <exception thrown>, <unknown> _exception :: e = _ [<unknown>] [<unknown>] Prelude> :steplocal *** Exception: Pattern match failure in do expression at ghc/GHCi/UI.hs:3149:12-18 }}} :step works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13773: Types are not normalized in instance declarations
by GHC 26 Nov '18

26 Nov '18

#13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | 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: -------------------------------------+------------------------------------- Consider the example below. It does not compile, but replacing 5*2 by 10 makes it compile. This is quite annoying since it forces me to do the normalization that the computer is really much better at doing. {{{#!hs module NatInstance where import GHC.TypeLits type N = 5 * 2 data D (n :: Nat) = D instance Show (D N) where show _ = "" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13773> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15085: :type-at/:all-types and :r don't mix
by GHC 25 Nov '18

25 Nov '18

#15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Put `x = ()` in test.hs. 2. Start ghci. 3. Turn on collection with :set +c. 4. Load the file with :l test.hs. 5. Observe the following output from :all-types {{{ test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () }}} 6. While ghci is still open, modify the file to say `x = True`. 7. In the same ghci session as before, reload with :r, or load the file again with :l test.hs, chef's choice. 8. Run :all-types again. After step 8, ghci prints the exact same thing as before, indicating that both sides of the equation have type `()`. It should instead update the source spans and types to match the file, reporting `Bool` instead of `()` and `(1,5)-(1,9)` for the second span. Manually exiting and restarting ghci appears to be the only way to freshen the collected type information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15495: Handling Source Locations via TTG
by GHC 24 Nov '18

24 Nov '18

#15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 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: -------------------------------------+------------------------------------- == Problem == The current implementation of [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG HsSyn AST] in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style. Besides the indirection and the resulting complications of the ping-pong style, there are two key problems with it: a. It bakes-in the source locations in the base TTG AST, forcing all instances to store source locations, even if they don't need them.For example, TH AST does not carry source locations, or even within GHC, there are generated terms without source locations. b. It results in a form of conceptual redundancy: source locations are tree decorations and they belong in the extension points. (see https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGr… TTG Guidance]) == Solution == We can move the source location decorations to a wrapper constructor and remove the ping-pong style. This can be done smoothly, mechanically, and gradually by using a getter/setter methods for source locations. More details can be found at [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… the related wiki page]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1)
by GHC 24 Nov '18

24 Nov '18

#15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCs detection of unused imports used to be very precise. But apparently this changed with GHC 8.0.1. I already noticed for a while that there is something fishy going on and finally came up with a minimal example. == Steps to reproduce: {{{#!hs -- Bar.hs module Bar (bar, module Control.Monad) where import Control.Monad bar :: Integer bar = 23 }}} {{{#!hs -- Foo.hs module Foo where import Bar import Control.Monad (forM_) foo :: Monad m => [a] -> (a -> m ()) -> m () foo = forM_ baz :: Integer baz = bar }}} {{{ $ ghci -Wall -Werror Foo.hs }}} **Expected result:** The program is reject. **Actual result:** The program was reject by GHC < 8.0.1, however later versions of GHC accept the program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15393> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15319: Configurable/overridable settings file
by GHC 23 Nov '18

23 Nov '18

#15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- GHC ships with a `settings` file. This file specifies what was known about the C compiler at GHC `./configure` time (whether to pass `-no-pie` etc, the path to the C compiler etc). Fortunately, I can override at least some of the entries of the `settings` file, e.g. to use a different GCC than the one GHC got to know about during the `./configure` phase. This is important because is multi-lingual projects, sometimes the build tool for the C++ part of the code wants a special compiler, which GHC should also be using when compiling C. The problem is that I can't override *everything*. If I supply via `-pgmc` a compiler that doesn't understand `-no-pie`, then I can't tell GHC to not pass `-no-pie`. Because I can't supply my own `settings` file, or (equivalently) there exists no CLI flag that allows me to override that particular entry in the `settings` file. What I'd like is something like: {{{ $ ghc -settings /path/to/settings/file }}} that subsumes `-pgmc` and other such flags. I'd be able to tell GHC in one go which compiler I want to use, and what flags GHC should or should not pass to that compiler depending on the features of the compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15319> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH
by GHC 23 Nov '18

23 Nov '18

#15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------------+---------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- I believe this is the same issue that is causing manually built `haddock` and `doctest` to crash on MacOS when fed TH (originally reported https://github.com/haskell/haddock/issues/767 and https://github.com/sol/doctest/issues/199) I've attached a minimal program that uses the GHC API and exhibits the same problem. {{{ $ ghc-8.4.2 -package ghc -package containers -package ghc-paths Prog.hs [1 of 1] Compiling Main ( Prog.hs, Prog.o ) Linking Prog ... $ ./Prog Main-no-TH.hs -package template-haskell $ ./Prog Main-TH.hs -package template-haskell Prog: lookupSymbol failed in relocateSection (RELOC_GOT) /usr/local/lib/ghc-8.4.2/integer-gmp-1.0.2.0/HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands' Prog: Prog: unable to load package `integer-gmp-1.0.2.0' }}} In case it isn't clear, I do not expect `Main-TH.hs` to crash `Prog`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory
by GHC 23 Nov '18

23 Nov '18

#15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: None | Version: Keywords: | Operating System: MacOS X Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is very difficult to install the ghc-8.6.1 release candidates (both RC1 and RC2) on MacOS because several components attempt to link directly to `/usr/local/opt/gmp/lib/libgmp.10.dylib`. This is not a standard path. See the offending `LC_LOAD_DYLIB` command here: {{{ $ jtool -l libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 00: LC_SEGMENT_64 Mem: 0x000000000-0x4e1000 __TEXT Mem: 0x0000010b0-0x0004d12ba __TEXT.__text (Normal) Mem: 0x0004d12ba-0x0004d1686 __TEXT.__stubs (Symbol Stubs) Mem: 0x0004d1688-0x0004d1cee __TEXT.__stub_helper (Normal) Mem: 0x0004d1cee-0x0004df75b __TEXT.__cstring (C-String Literals) Mem: 0x0004df760-0x0004e0f40 __TEXT.__const Mem: 0x0004e0f40-0x0004e1000 __TEXT.__unwind_info LC 01: LC_SEGMENT_64 Mem: 0x0004e1000-0x5a7000 __DATA Mem: 0x0004e1000-0x0004e30f0 __DATA.__got (Non-Lazy Symbol Ptrs) Mem: 0x0004e30f0-0x0004e3100 __DATA.__nl_symbol_ptr (Non-Lazy Symbol Ptrs) Mem: 0x0004e3100-0x0004e3610 __DATA.__la_symbol_ptr (Lazy Symbol Ptrs) Mem: 0x0004e3610-0x0004e3618 __DATA.__mod_init_func (Module Init Function Ptrs) Mem: 0x0004e3620-0x0004f4bc0 __DATA.__const Mem: 0x0004f4bc0-0x0005a6920 __DATA.__data Mem: 0x0005a6920-0x0005a6928 __DATA.__bss (Zero Fill) LC 02: LC_SEGMENT_64 Mem: 0x0005a7000-0xb8c000 __LINKEDIT LC 03: LC_ID_DYLIB @rpath/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib LC 04: LC_DYLD_INFO LC 05: LC_SYMTAB Symbol table is at offset 0x6a5348 (6968136), 118090 entries String table is at offset 0x873d78 (8863096), 3241616 bytes LC 06: LC_DYSYMTAB 81438 local symbols at index 0 35948 external symbols at index 81438 704 undefined symbols at index 117386 No TOC No modtab 1380 Indirect symbols at offset 0x8727e8 LC 07: LC_UUID UUID: B4C0C347-131F-317B-BA52-EE23F5C5CABA LC 08: LC_VERSION_MIN_MACOSX Minimum OS X version: 10.12.0 LC 09: LC_SOURCE_VERSION Source Version: 0.0.0.0.0 LC 10: LC_LOAD_DYLIB /usr/lib/libiconv.2.dylib LC 11: LC_LOAD_DYLIB @rpath/libHSinteger- gmp-1.0.2.0-ghc8.6.0.20180714.dylib LC 12: LC_LOAD_DYLIB @rpath/libHSghc- prim-0.5.3-ghc8.6.0.20180714.dylib LC 13: LC_LOAD_DYLIB /usr/local/opt/gmp/lib/libgmp.10.dylib LC 14: LC_LOAD_DYLIB /usr/lib/libSystem.B.dylib LC 15: LC_RPATH @loader_path/../integer-gmp-1.0.2.0 LC 16: LC_RPATH @loader_path/../ghc-prim-0.5.3 LC 17: LC_RPATH @loader_path/../rts LC 18: LC_FUNCTION_STARTS Offset: 6876632, Size: 91504 (0x68edd8-0x6a5348) with 83924 functions LC 19: LC_DATA_IN_CODE Offset: 6968136, Size: 0 (0x6a5348-0x6a5348) }}} The other offenders are `libHSbinary` and `libHSinteger-gmp`. Without changing these load commands, you'll get the following error: {{{ $ ./configure --prefix=... $ make install <snip> dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: ./libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.0.20180714.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} I tried passing the `--with-gmp-libraries` option to `configure`, but that did not help. I guess this is just a packaging problem, but figured you should be aware before the official release... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14