March 2015 - ghc-tickets

[GHC] #10074: Implement the 'Improved LLVM Backend' proposal
by GHC 01 Feb '18

01 Feb '18

#10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: task | Milestone: 7.12.1 Priority: high | Version: Component: Compiler | Operating System: Unknown/Multiple (LLVM) | Type of failure: None/Unknown Keywords: llvm, | Blocked By: codegen | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: Phab:D530 | -------------------------------------+------------------------------------- This is a meta ticket designed to reflect the current implementation status of the 'Improved LLVM Backend' proposal, documented here: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10074> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 34

[GHC] #9885: ghc-pkg parser eats too much memory
by GHC 22 Jan '18

22 Jan '18

#9885: ghc-pkg parser eats too much memory -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Moderate (less | performance bug than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Parsing of spec files in ghc-pkg scales very poorly. The following script demonstrates memory consumption growth as a function of the number of tokens in ld-options (16K leads to ~6G) #!/bin/bash # Demonstrates memory consumption behavior of ghc-pkg as a function of # the number of ld-options arguments. for i in {10..14}; do size=$((1 << $i)) echo $size rm -fr a.packages /usr/bin/ghc-pkg init a.packages cat > a.spec <<EOF name: project id: project license: AllRightsReserved version: 1.0 EOF echo -n ld-options: >> a.spec for i in $(seq 1 $size); do echo -n "x "; done >> a.spec /usr/bin/time /usr/bin/ghc-pkg --global-package-db a.packages register --force a.spec done exit 0 # This was collected with ghc-7.6.3. 7.8.3 fares as badly. % bash a.sh 1024 Reading package info from "a.spec" ... done. 0.03user 0.00system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 17848maxresident)k 0inputs+32outputs (0major+4973minor)pagefaults 0swaps 2048 Reading package info from "a.spec" ... done. 0.09user 0.01system 0:00.10elapsed 99%CPU (0avgtext+0avgdata 60872maxresident)k 0inputs+56outputs (0major+15723minor)pagefaults 0swaps 4096 Reading package info from "a.spec" ... done. 0.41user 0.07system 0:00.49elapsed 99%CPU (0avgtext+0avgdata 294340maxresident)k 0inputs+104outputs (0major+74090minor)pagefaults 0swaps 8192 Reading package info from "a.spec" ... done. 1.72user 0.30system 0:02.04elapsed 99%CPU (0avgtext+0avgdata 1168836maxresident)k 0inputs+192outputs (0major+292716minor)pagefaults 0swaps 16384 Reading package info from "a.spec" ... done. 9.11user 1.38system 0:10.51elapsed 99%CPU (0avgtext+0avgdata 5396932maxresident)k 0inputs+376outputs (0major+1349736minor)pagefaults 0swaps -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9885> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9285: IO manager startup procedure somewhat odd
by GHC 15 Jan '18

15 Jan '18

#9285: IO manager startup procedure somewhat odd ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently the RTS startup procedure for the threaded runtime with a single capability looks something like this: '''1. Capability gets initialized''' {{{ hs_main real_main hs_init_ghc initScheduler initCapabilities }}} '''2. IO Manager is started''' {{{ hs_main real_main hs_init_ghc ioManagerStart }}} '''3. ensureIOManagerIsRunning''' The IO manager of course is mostly written in Haskell, so `ioManagerStart` does {{{ cap = rts_lock(); rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); rts_unlock(cap); }}} '''4. Bound task is created and we start running Haskell code''' Since this is the first call to `rts_lock`, it creates a bound task to correspond to the current OS thread. '''5. Haskell code does a safe FFI call: create worker task 1''' The first safe FFI call that the IO manager makes (ignoring `labelThread`) is to `c_setIOManagerControlFd`. At this point, the bound task gets suspended and we create a worker task. '''6. Worker task 1 starts executing `GHC.Event.Manager.loop`''' The worker tasks gets suspended due to an explicit call to `yield` in `GHC.Event.Manager.step`, at which point the bound task continues execution. It continues and finishes (`ensureIOManagerRunning` completes). The worker task takes over. '''7. Worker task 1 does a safe FFI call to `I.poll`, create new worker task 2''' (This safe call is from `GHC.Event.Manager.step`) '''8. Worker task 2 executes `GHC.Event.TimerManager.loop`, and does safe FFI call to `I.poll`; create worker task 3''' This worker task will remain spare for now. '''9. Start executing the actual main function''' The IO manager calls `rts_unlock`, which verifies if there are any spare workers available; it finds that there are and doesn't start a new one. Then when we start `main` itself of course we go through this `rts_lock, rts_evalIO, rts_unlock` sequence ''again''. This is somewhat confusing, and makes tracing the startup of the code more difficult to interpret. It seems that this could be simpler: only a single `rts_lock` should be necessary, in which we first call `ensureIOManagerIsRunning` and then `main`, followed by a single `rts_unlock`. A similar simplification should be possible in `forkProcess`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8487: Debugger confuses variables
by GHC 02 Jan '18

02 Jan '18

#8487: Debugger confuses variables ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Consider the following example: {{{ import Control.Exception f = do ma <- try $ evaluate a case ma of Right str -> return a Left err -> return $ show (err :: SomeException) where a :: String a = error "hi" }}} Load into ghci, set a breakpoint on the 5th line, then run f: {{{ :break 5 f }}} You will get {{{ Stopped at Ex.hs:(5,3)-(7,53) _result :: IO String = _ a :: Either SomeException String = Left _ }}} This doesn't make sense. `a` has type `String`; it is `ma` that has type `Either SomeException String`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8642: Allow GHCi to print non-pretty forms of things.
by GHC 29 Dec '17

29 Dec '17

#8642: Allow GHCi to print non-pretty forms of things. ------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- Currently when we ask GHCi for :info or :type of something, it will do things like splitting over multiple lines and all that eye candy that people like to see. This however makes it more difficult for people to write text editor plugins &c that rely on GHCi output. Currently one has to write parsers to stitch the GHCi output back together which is fairly error prone and not really future-proof. Is there any chance for a more machine-friendly output? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9291: Don't reconstruct sum types if the type subtly changes
by GHC 28 Dec '17

28 Dec '17

#9291: Don't reconstruct sum types if the type subtly changes ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: ----------------------------------------------+---------------------------- Consider this test case: {{{ module Main (main) where fun :: Either Int String -> Either String String fun x = case x of Left int -> Left (show int) Right str -> Right str {-# NOINLINE fun #-} main :: IO () main = do l <- getLine print $ fun (Right l) }}} The core we get for fun looks like: {{{ Main.fun [InlPrag=NOINLINE] :: Data.Either.Either GHC.Types.Int GHC.Base.String -> Data.Either.Either GHC.Base.String GHC.Base.String [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType <S,1*U>] Main.fun = \ (x_aur :: Data.Either.Either GHC.Types.Int GHC.Base.String) -> case x_aur of _ [Occ=Dead] { Data.Either.Left int_aus -> Data.Either.Left @ GHC.Base.String @ GHC.Base.String (GHC.Show.$fShowInt_$cshow int_aus); Data.Either.Right str_aCG -> Data.Either.Right @ GHC.Base.String @ GHC.Base.String str_aCG } }}} There would be less allocations and probably perform better if we just coerced `x` into the new type. Because the coercion is common code, this also means that if hypothetically some other sum type which had 15 constructors, and only 3 had subtle type changes, 12 of the case branches could be CSE'd into the single coerce greatly reducing code generated and also hinting the inliner better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9291> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure
by GHC 22 Dec '17

22 Dec '17

#10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When characterizing bytestring's `Builder` interface[1] I noticed that some benchmarks involving repeated appends (e.g. `Host endian/1MB of Word8 in chunks of 16`) perform inexplicably much worse than others. A glance at the assembly revealed that a large number of `Word8`s are being evaluated and saved to registers, only to be later stored. E.g., ```#!asm # First we evaluate a number of Word8s, saving them in registers movzbl %bl,%ebx leaq 1(%r14),%rcx movzbl %cl,%ecx leaq 2(%r14),%rdx movzbl %dl,%edx leaq 3(%r14),%rsi movzbl %sil,%esi leaq 4(%r14),%r9 movzbl %r9b,%r9d leaq 5(%r14),%r10 movzbl %r10b,%r10d ... # Eventually we run out of registers and start spilling to the stack movq %rax,64(%rsp) leaq 7(%r14),%rax movzbl %al,%eax movq %rbx,72(%rsp) ... # Only after evaluating all of the needed words do we actually consume # them movq %rax,-152(%r12) movq 72(%rsp),%rax movq %rax,-144(%r12) movq 80(%rsp),%rax movq %rax,-136(%r12) movq 88(%rsp),%rax movq %rax,-128(%r12) ... movq %rsi,-56(%r12) movq %r9,-48(%r12) movq %r10,-40(%r12) movq %r11,-32(%r12) movq %r14,-24(%r12) ``` This is due to the fact that the `Word`s are bound outside of a case analysis and GHC is reluctant to push them inside of the branches. The float-in pass will only float a binding into a case if the value is "small" and at least one branch doesn't use the binding. Unfortunately the case expression in question has only two branches. This is demonstrated in the attached testcase. [1] https://github.com/kolmodin/binary/pull/65 [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables
by GHC 18 Dec '17

18 Dec '17

#9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------+------------------------------------------------- Reporter: | Owner: stusmith | Status: new Type: | Milestone: feature request | Version: 7.6.3 Priority: | Operating System: Unknown/Multiple normal | Type of failure: Incorrect warning at Component: | compile-time Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- GHC already warns about variable shadowing: {{{ timesTwoPlusOne x = timesTwo x + 1 where timesTwo x = x * 2 Warning: This binding for `x' shadows the existing binding bound at <location> }}} However the similar warning doesn't happen for type variables. {{{ tryMaybe :: IO a -> IO (Maybe a) tryMaybe action = do result <- (try action) :: IO (Either SomeException a) return $ case result of Left _ -> Nothing Right v -> Just v Couldn't match type `a' with `a1' `a' is a rigid type variable bound by the type signature for tryMaybe :: IO a -> IO (Maybe a) at types.hs:<line>:13 `a1' is a rigid type variable bound by an expression type signature: IO (Either SomeException a1) at types.hs:<line>:15 Expected type: IO a1 Actual type: IO a ... }}} Here, I thought that the 'a' in the function's type declaration was the same 'a' in the expression type declaration. However in Haskell 98, they are completely different variables. Suggestion: if a type variable is renamed by the compiler due to a clash with another type variable, issue a warning that the second shadows the first, and give a hint about using -XScopedTypeVariables and forall. Alternative suggestion: if an error is displayed, where the error contains a renamed type variable, issue a hint that the second shadows the first, and give a hint about using -XScopedTypeVariables and forall. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all
by GHC 16 Dec '17

16 Dec '17

#8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all ----------------------------------------------+---------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Keywords: callingConvention | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- testing if SpLim=$rbp and Sp=$rsp changed performance at all would need a stack check but then push could be used to spill to the stack Idea via Nathan Howell. At the very least, the x86 PUSH instruction has a more succinct encoding than MOV. worth hacking out to see if this can measurable shift ghc perf on nofib or not. this would be part of a larger effort to explore ways to improve GHC's calling convention for modern hardware -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8272> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters
by GHC 14 Dec '17

14 Dec '17

#9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: linux, terminal, | Operating System: colour, color, prompt | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Hi, there's an issue in the GHCi prompt. To reproduce: 1. Do everything in Linux (I don't have other operating systems); I'm using a version of the gnome 2 gnome-terminal. 2. Use the following to colourise the prompt in GHCi: echo -e :set prompt '"\033[32;1m%s\033[34;1m>\033[0m "' >> ~/.ghc/ghci.conf 3. Import quite a few modules (say, 5 to 10 should be enough) 4. Give the prompt enough text that it wraps around. It's best if you start the text with -- so that it's a comment and doesn't produce any output. For example, say I entered "-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb", I now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb (do note that the first set of b's is located on the same line as the prompt, and the second is located under the prompt) 5. Press Enter. You should now see: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> 6. Press Ctrl-P or the up arrow key to select the previous history item. You will now see the following: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 7. Press Ctrl-A or the Home cursor key to go to the beginning of the text entry, and then type X. You will now see the last prompt to be: *Types Control.Monad.Writer Control.Monad Data.Functor Control.Applicative Data.Monoid> -- bbbbbbbbbbbbX-- bbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 8. If you press Enter, you will find out that prompt was actually (without line breaks): X-- bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb I tried resizing the terminal window to 45 chars to make the lines above shorter; I imported Data.Monoid and Data.Functor in a new GHCi. The prompt contained garbage, most likely badly wrapped escape codes. See attachment. As both likely are a single bug in disguise, I include both reports in this ticket. Creating a test case for whether things actually work in a terminal might be difficult, but creating test for whether things get wrapped correctly (and not testing how things work out in a terminal) should be simple if annoying. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9364> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7