September 2018 - ghc-tickets

[GHC] #15560: Full laziness destroys opportunities for join points
by GHC 05 Nov '18

05 Nov '18

#15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14287 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Even if we already know a binding is a join point we STILL float it to the top and turn it into a function. The simple example below results in a join point after the first simplifier run. Then we run the float out pass immediately undoing this by making it a top level binding. It then stays at the top till we are done resulting in the core I've put in the comments. {{{ #!haskell data T = A | B | C | D | E | F | G {-# NOINLINE n #-} n :: T -> T n A = B n B = C n _ = A f :: Int -> T -> T -> T f sel x y = -- function large enough to avoid being simply inlined let j z = n . n . n . n . n . n $ z in case sel of -- j is always tailcalled 0 -> j x _ -> j y -- j is floated to top level instead of ending up as joinpoint. -- T.f_j -- = \ (eta_B1 [OS=OneShot] :: T) -> n (n (n (n (n (n eta_B1))))) -- -- RHS size: {terms: 14, types: 6, coercions: 0, joins: 0/0} -- f :: Int -> T -> T -> T -- f = \ (sel_aYP :: Int) (x_aYQ :: T) (y_aYR :: T) -> -- case sel_aYP of { GHC.Types.I# ds_d2fL -> -- case ds_d2fL of { -- __DEFAULT -> T.f_j y_aYR; -- 0# -> T.f_j x_aYQ -- } -- } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15560> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #15009: Float equalities past local equalities
by GHC 05 Nov '18

05 Nov '18

#15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider the two datatypes {{{#!hs data T1 a where MkT1 :: a ~ b => b -> T1 a data T2 a where MkT2 :: a -> T2 a }}} To me, these look like two ways of writing the same thing. Yet they participate quite differently in type inference. If I say {{{#!hs f (MkT1 a) = not a g (MkT2 a) = not a }}} then `g` is accepted (with type `T2 Bool -> Bool`) while `f` is rejected as GHC mutters about untouchable type variables. Of course, GHC's notion of untouchable type variables is a Good Thing, with arguments I won't rehearse here. It all boils down to this rule: (*) Information that arises in the context of an equality constraint cannot force unification of a unification variable born outside that context. I think this rule is a bit too strict, though. I propose a new rule: (%) Information that arises in the context of a ''non-purely-local'' equality constraint cannot force unification of a unification variable born outside that context. where '''Definition:''' An equality constraint is ''purely local'' if every type variable free in the constraint has the same scope as the constraint itself. That is, if an equality constraint mentions only variables freshly brought into scope -- and no others -- then we can still unify outer unification variables. Happy consequences of this choice: * `f` above could be accepted, as the equality in `MkT1` is purely local. * Rule (%) allows users to effectively let-bind type variables, like this: {{{#!hs f :: forall a. (a ~ SOME REALLY LONG TYPE) => Maybe a -> Maybe a -> Either a a }}} Currently, this kind of definition (if it's, say, within a `where` clause) triggers rule (*) in the body of the function, and thus causes type inference to produce a different result than just inlining `SOME REALLY LONG TYPE`. * We could theoretically simplify our treatment of GADTs. Right now, if you say {{{#!hs data G a b c where MkG :: MkG d Int [e] }}} GHC has to cleverly figure out that `d` is a universal variable and that `e` is an existential, producing the following Core: {{{#!hs data G a b c where MkG :: forall d b c. forall e. (b ~ Int, c ~ [e]) => MkG d b c }}} If we use rule (%), then I believe the following Core would behave identically: {{{#!hs data G a b c where MkG :: forall a b c. forall d e. (a ~ d, b ~ Int, c ~ [e]). MkG a b c }}} This treatment is more uniform and easier to implement. (Note that the equality constraints themselves are unboxed, so there's no change in runtime performance.) What are the downsides of (%)? I don't think there are any, save an easy extra line or two in GHC to check for locality. Rule (*) exists because, without it, GHC can infer non-principal types. However, I conjecture that Rule (%) also serves to require inference of only principal types, while being more permissive than Rule (*). I'm curious for your thoughts on this proposal. (I am making it here, as this is really an implementation concern, with no discernible effect on, say, the user manual, although it would allow GHC to accept more programs.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #13904: LLVM does not need to trash callee-saved registers.
by GHC 03 Nov '18

03 Nov '18

#13904: LLVM does not need to trash callee-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: llvm, codegen | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #4992 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **Summary**: This ticket is a simplification of the LLVM backend that I already plan to do in another branch, but I'd like to push the patch into `master`, and then merge from `master` into that branch. The LLVM backend attempts to trash the physical registers corresponding to Rx, Fx, and Dx registers that are caller-saved before an FFI call by emitting a sequence such as this: {{{#!llvm store i64 undef, i64* %R3_Var store i64 undef, i64* %R4_Var store i64 undef, i64* %R5_Var store i64 undef, i64* %R6_Var store float undef, float* %F1_Var store double undef, double* %D1_Var store float undef, float* %F2_Var store double undef, double* %D2_Var store float undef, float* %F3_Var store double undef, double* %D3_Var store float undef, float* %F4_Var store double undef, double* %D4_Var store float undef, float* %F5_Var store double undef, double* %D5_Var store float undef, float* %F6_Var store double undef, double* %D6_Var %ln7bu = call ccc double (double) @llvm.sin.f64( double %ln7bs ) nounwind }}} Where the Rx/Fx/Dx registers are chosen based on what physical register those global registers map to, and whether those physical registers are caller-saved according to the C ABI. I'm certain this is unnecessary, as there is no way to know the physical register corresponding to those vars within an LLVM IR function. The calling convention used for the FFI call will preserve caller-saved registers as needed, i.e., only if such a value is needed after the call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness
by GHC 02 Nov '18

02 Nov '18

#14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7210 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data A = A { a :: {-# UNPACK #-} Maybe Int} }}} {{{ [1 of 1] Compiling Main ( Temp.hs, Temp.o ) Temp.hs:1:19: error: • Unexpected strictness annotation: {-# UNPACK #-}Maybe • In the type ‘{-# UNPACK #-}Maybe Int’ In the definition of data constructor ‘A’ In the data declaration for ‘A’ | 1 | data A = A { a :: {-# UNPACK #-} Maybe Int} | }}} The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite. A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level
by GHC 01 Nov '18

01 Nov '18

#15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- A file A defines a typeclass, and gives an instance for all types a, and exports a function relying on said typeclass. A file B defines a data type, makes it a specific `OVERLAPPING` instance of that class, and uses the function defined in A. Which instance ends up being picked for B depends on the optimisation level those files are compiled with. **Minimal test case** //A.hs// {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# OPTIONS_GHC -fno-warn-simplifiable-class-constraints #-} module A where import Data.Maybe class A a where someValue :: a -> Maybe Int instance A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} //B.hs// {{{#!hs module B where import A data B = B Int instance {-# OVERLAPPING #-} A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 }}} //Main.hs// {{{#!hs import B main :: IO () main = putStrLn $ "B: " ++ show getBInt }}} To reproduce: {{{ $ ghc -O0 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 42 $ ghc -O2 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 0 }}} The fix introduced to fix ticket:14434 instructs the "short-cut solver" to not automatically choose a matching instance if it marked as `INCOHERENT` or `OVERLAPPABLE`, but in this case the instance is not marked in any way. This might be the source of the bug? Additionally, whatever the optimisation level, ghc emits a warning about the `A a =>` class constraint being simplifiable; but if it is removed, then the program prints "0" in both cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15654: Use deriving Functor in the codebase
by GHC 01 Nov '18

01 Nov '18

#15654: Use deriving Functor in the codebase -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.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: -------------------------------------+------------------------------------- In many places in compiler/ we manually define a Functor instance (`git grep "instance Functor"` shows 60). I think we could switch to `deriving` in most (or all?) cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15494: Cannot install GHC through stack on NixOS
by GHC 31 Oct '18

31 Oct '18

#15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: install | Operating System: Linux fail,NixOS,Linux | Type of failure: Installing GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- stack setup gives me this error: Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ Possibly a domain-specific problem,caused by NixOS's file-system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so
by GHC 31 Oct '18

31 Oct '18

#14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: 1. Make a pristine git checkout 2. Follow the steps outlined in https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart, uncommenting the `BuildFlavour = prof` line in `build.mk`, to build and install ghc. 3. Check ghc version to verify that this ghc build is the one in `/usr/local/bin` 4. Try to compile the following `hello.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH main = putStrLn $(litE (stringL "Hello")) }}} It should fail with an error message similar to: {{{ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.3.20171120 for x86_64-unknown-linux): Dynamic linker not initialised CallStack (from -prof): Linker.CAF (<entire-module>) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} and: {{{ <no location info>: error: <command line>: can't load .so/.DLL for: libHSghc-prim-0.5.2.0.so (libHSghc-prim-0.5.2.0.so: cannot open shared object file: No such file or directory) }}} By contrast, the following do *not* trigger the error: - Building GHC without uncommenting the `BuildFlavour` line in `build.mk` - Compiling with the `inplace/bin/ghc-stage2` in the GHC source tree - Compiling a `hello.hs` that does not use TemplateHaskell Further system info: - Debian 9 - Cabal version 1.24 - GHC 8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build
by GHC 29 Oct '18

29 Oct '18

#9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Takano Akio's [https://github.com/takano-akio/ww-fusion worker-wrapper fusion] modifies `foldr/build` fairly conservatively to allow safe fusion of `foldl` and friends without relying on arity analysis. This advantage is important for two reasons that I know of: 1. As discussed in Joachim Breitner's original paper, the current arity analysis is unable to infer arity correctly when facing certain forms of recursion. 2. The current arity analysis, and probably ''any'' practical arity analysis, depends on inlining to a degree that can sometimes be unhealthy. I would love to make functions like `hPutStr` fuse, but I suspect doing so safely at present would likely cause a code explosion—the function being folded is too large to want to inline to make it available for arity analysis following fusion. I don't understand it completely yet, but it looks like `foldrW/buildW` can eliminate a lot of this uncertainty. Furthermore, it appears that functions currently written using `foldr` in a "right-handed" way can remain unchanged, using an implementation of `foldr` in terms of `foldrW`. Only "left-handed" folds will need to be rewritten to take advantage of this framework, along with all the `build`s. That said, `foldrW/buildW` probably has its weaknesses too. The basic fusion rule looks like this. {{{#!hs {-# RULES "foldrW/buildW" forall f z (i :: Wrap f b) (g :: forall c g . (Wrap g c) -> (a -> c -> c) -> c -> c) . foldrW i f z (buildW g) = g i f z #-} }}} If `g` and `i` are not inlined sufficiently to merge with each other, I imagine this could produce worse results than `foldr/build` when the latter works properly. The only way to really get a feel for performance would be to carefully modify everything to work as well as it can with this framework and see how the results compare. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9374: Investigate Static Argument Transformation
by GHC 29 Oct '18

29 Oct '18

#9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with `-fstatic-argument-transformation`. The comment in DynFlags says: {{{ Max writes: I think it's probably best not to enable SAT with -O2 for the 6.10 release. The version of SAT in HEAD at the moment doesn't incorporate several improvements to the heuristics, and I'm concerned that without those changes SAT will interfere with some attempts to write "high performance Haskell", as we saw in some posts on Haskell-Cafe earlier this year. In particular, the version in HEAD lacks the tail call criterion, so many things that look like reasonable loops will be turned into functions with extra (unneccesary) thunk creation. }}} 6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30