November 2017 - ghc-tickets

[GHC] #14152: Float exit paths out of recursive functions
by GHC 08 Oct '18

08 Oct '18

#14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14137 #10918 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of a discussion from #14137. == The problem == We generally avoid inlining or floating a binding into a recursive function, because we do not want to duplicat work/allocations. But sometimes the binding is only used inside the recursive function on the “exit path”. In which case it would be good to inline. Example: {{{#!hs let x = f x0 in let go 10 = h x go i = go (i+1) in go (0::Int) + 100 }}} It would be beneficial to inline `x`. The problem is that it is not very obvious that this occurence of `x` is ok for inlining. In particular, it is not syntactically visible. == Proposed solution == If we apply loopification (#14068), this would turn into {{{#!hs let x = f x0 in let go n = joinrec jgo 10 = h x jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''first joinrec normal form'', defined as “every recursive function where all recursive calls are tail-recursive is a recursive join point”. This ticket proposes to transform this even further and ''float out all case alternatives that do not mention `jgo` as non-recursive join- points'', as so: {{{#!hs let x = f x0 in let go n = join jexit = h x joinrec jgo 10 = call jexit jgo i = call jgo (i+1) in call jgo n in go (0::Int) + 100 }}} I’d like to call this ''second `joinrec` normal form'', defined as “in first `joinrec` normal form, and all subexpressions of a recursive join point `j` that are in tail-call position and do not mention `j` are join calls”. If the floated expression has free variables that are bound inside the `joinrec`, they turn into parameters of the newly created joinpoint. At this point, GHC can tell that `go` is called at most once, and will therefore happily inline `x` into the right hand side of `jexit. == Alternative solutions == Ticket #10918 uses Call Arity results to learn that `x` is one-Shot, and inline it even in the original code. This works, but the problem is that float-out will undo this. See [ticket:10918#comment:5]. == Limitation === It only works for recursive functions that are join points, or can be turned into join points by loopification (#14068). It does not work forexample for {{{#!hs let x = f x0 let go 0 = h x go n = (go (n-1) + 1 in go 10 }}} although it would be equally desirable to float `h x` out of `go` so that `x` can be inlined. == Preservation == A remaining tricky point is that we need to stop one of these carefully- constructed non-recursive join points being inlined into a recursive join point, even if it is invoked at just one place. That should not be hard. And in a final run of the simplifer (or in CorePrep) we could switch off that restriction and let it inline. (Ticket #14137 is about inlining ''more'' join points into recursive join points, so it is the antithesis to the present ticket.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 45

[GHC] #13896: Use response file to invoke hsc2hs
by GHC 07 Oct '18

07 Oct '18

#13896: Use response file to invoke hsc2hs ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: hsc2hs | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- We already use response files when invoking Haddock due to Windows command line length limitations. It [[https://github.com/haskell/cabal/issues/3122#issuecomment-311489312|seems]] that we also need to do the same with `hsc2hs`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13841: ADOPT pragma for silencing orphan instances warnings per instance
by GHC 07 Oct '18

07 Oct '18

#13841: ADOPT pragma for silencing orphan instances warnings per instance -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Currently GHC only allows enabling and disabling the warnings about orphan instances on a module level. I’d like to have an ADOPT pragma that allows disabling the warning for specific instance: {{{#!haskell instance {-# ADOPT #-} C Int }}} Apart from disabling the warning about orphan instances for this specific instance, this pragma should have no effect. I already hacked together a [https://github.com/cocreature/ghc/tree/adopt- pragma prototype] and I’m willing to clean that up and submit a diff if other people like this. This does change the surface language but disabling a warning seem too small of an effect for the ghc proposals process (I’m happy to make a proposal if you disagree). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12469: Memory fence on writeIORef missing on ARM
by GHC 06 Oct '18

06 Oct '18

#12469: Memory fence on writeIORef missing on ARM ------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: memory model | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------+------------------------------------- The memory model question has been debated now and again. his thread from ten years back (https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html) lays out the basic situation with thunk update, writeIORef, and memory fences. But we recently began experimenting with GHC on ARM platforms, and it seems to lack a memory fence that the participants in the cited thread expect it to have. Here's an attempt to construct a program which writes fields of a data structure, and then writes the pointer to that structure to an IORef, without the proper fence inbetween: ```Haskell import Data.IORef import Control.Concurrent data Foo = Foo Int deriving Show {-# NOINLINE mkfoo #-} mkfoo x = Foo x {-# NOINLINE dowrite #-} dowrite r n = writeIORef r $! mkfoo n main = do r <- newIORef (Foo 3) forkIO (dowrite r 4) x <- readIORef r print x ``` Here's the relevant bits of the CMM that results when compiled on an ARM 64 machine: ```C mkfoo_rn1_entry() // [] { [] } {offset c40i: P64[MainCapability+872] = P64[MainCapability+872] + 16; if (P64[MainCapability+872] > I64[MainCapability+880]) goto c40m; else goto c40l; c40m: I64[MainCapability+928] = 16; P64[MainCapability+24] = mkfoo_rn1_closure; call (I64[MainCapability+16])(R1) args: 16, res: 0, upd: 8; c40l: I64[P64[MainCapability+872] - 8] = Foo_con_info; P64[P64[MainCapability+872]] = P64[I64[MainCapability+856]]; P64[MainCapability+24] = P64[MainCapability+872] - 7; I64[MainCapability+856] = I64[MainCapability+856] + 8; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } ``` ```C dowrite_entry() // [] { [] } {offset c44j: call a_r3Dy_entry() args: 24, res: 0, upd: 8; } } a_r3Dy_entry() // [R1] { [] } {offset c41D: if (I64[MainCapability+856] - 16 < I64[MainCapability+864]) goto c41H; else goto c41I; c41H: P64[MainCapability+24] = a_r3Dy_closure; call (I64[MainCapability+16])(R1) args: 24, res: 0, upd: 8; c41I: I64[I64[MainCapability+856] - 8] = block_c41B_info; P64[I64[MainCapability+856] - 16] = P64[I64[MainCapability+856] + 8]; I64[MainCapability+856] = I64[MainCapability+856] - 16; call mkfoo_rn1_entry() args: 16, res: 8, upd: 8; } } block_c41B_entry() // [R1] { [] } {offset c41B: _s3Ep::P64 = P64[I64[MainCapability+856] + 8]; I64[I64[MainCapability+856] + 8] = block_c41G_info; _s3Es::P64 = P64[MainCapability+24]; P64[MainCapability+24] = _s3Ep::P64; P64[I64[MainCapability+856] + 16] = _s3Es::P64; I64[MainCapability+856] = I64[MainCapability+856] + 8; if (P64[MainCapability+24] & 7 != 0) goto u41S; else goto c41K; u41S: call block_c41G_entry(R1) args: 0, res: 0, upd: 0; c41K: call (I64[I64[P64[MainCapability+24]]])(R1) args: 8, res: 8, upd: 8; } } block_c41G_entry() // [R1] { [] } {offset c41G: _s3Ev::P64 = P64[P64[MainCapability+24] + 7]; P64[_s3Ev::P64 + 8] = P64[I64[MainCapability+856] + 8]; call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] dirty_MUT_VAR(MainCapability+24, _s3Ev::P64); P64[MainCapability+24] = ()_closure+1; I64[MainCapability+856] = I64[MainCapability+856] + 16; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } ``` The fence should happen before the write of the pointer into the IORef. I can't find the fence, and can't find a codepath in the compiler that would insert it (i.e. with MO_WriteBarrier). `dirty_MUT_VAR` is actually too late to perform the fence, but it doesn't either: ```C void dirty_MUT_VAR(StgRegTable *reg, StgClosure *p) { Capability *cap = regTableToCapability(reg); if (p->header.info == &stg_MUT_VAR_CLEAN_info) { p->header.info = &stg_MUT_VAR_DIRTY_info; recordClosureMutated(cap,p); } } ``` (Neither does `recordClosureMutated`.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12469> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33

[GHC] #13477: Turn cIntegerLibraryType into a dynflag
by GHC 05 Oct '18

05 Oct '18

#13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: GHC API | Version: 8.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: -------------------------------------+------------------------------------- Currently, at configure time we tell GHC whether integers are built using `integer-gmp` or `integer-simple`, and this gets baked in via the global constant `cIntegerLibraryType`. This is all fine for normal use of GHC (the program), but users of ghc (the library) might want to have more leeway here. A good solution seems to be turn this into a dynflag setting, so that users of the GHC API can adjust that as fit. From a cursory glance at the code, this does not seem to be a big problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13753: Improve GHC's ghc package environment lookup logic
by GHC 05 Oct '18

05 Oct '18

#13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.2.2 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: -------------------------------------+------------------------------------- Documentation for package enviroments which describes the current lookup logic: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.ht… #package-environments There's two things I'd like to improve: 1. Define a special magic "null" environment, which instructs GHC to ignore any package environment files. To this end, I propose to use the name `-` (i.e. a single dash), as that is more portable than using the empty string for environment variables. In other words: * `-package-env -` or * `GHC_ENVIRONMENT=-` (unless a `-package-env` flag which has higher priority overrides it) would prevent GHC from interpreting any package environment files. 2. Provide a way to disambiguate environment names (i.e. those that are looked up in `$HOME/.ghc/arch-os-version/environments/name`) and environment files arguments. Currently, if you say `GHC_ENVIRONMENT=test` then a local file `test` would shadow the environment named `test` which would result in rather confusing errors. Instead I suggest to have package-env identifiers be interpreted as "names" by default, and only if they look like relative or absolute paths (i.e. `./foobar` or `/home/foo/...`) be interpreted as file locations (relative to $CWD). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13753> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13861: Take more advantage of STG representation invariance (follows up #9291)
by GHC 05 Oct '18

05 Oct '18

#13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 following `case` alternatives at the STG stage (i.e. untyped) : {{{#!hs case scrut of False -> [] Just x -> Right x [] -> Nothing }}} The common theme of all these is that the scrutinee's memory layout and the result's memory layout coincide. So operationally no allocation needs to take place, and the whole `case` expression is simply a (strict) identity at the STG stage. I propose to add a small STG analysis to: * for each `case` alternative check whether the assigned tag between scrutinee and result matches, and if so * check whether both have the underlying memory layout and contents. If these conditions are met, the case alternative can be replaced with the identity. When all alternatives simplify to the identity (also considering the DEFAULT alternative), then the entire `case` expression reduces to a single identity DEFAULT alternative (i.e. all other alternatives in the `case` can be dropped). Many of the code examples in the join points paper (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/join- points-pldi17.pdf) exhibit these optimisation opportunities. The already implemented suggestion in #9291 comes with the restriction that it only operates in the scope of the same type (see last comment there), but STG is untyped, so why not take advantage of this fact? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13861> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14391: Make the simplifier independent of the typechecker
by GHC 05 Oct '18

05 Oct '18

#14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed that the simplifier module depends on all of the type checker, and HsSyn stuff, and renamer stuff, which I found strange. After a little investigation, it seems that the simplifier depends on CoreMonad, and that pulls some very few type-checker related things: 1. {{{ import TcRnMonad ( initTcForLookup ) import {-# SOURCE #-} TcSplice ( lookupThName_maybe ) }}} for {{{ thNameToGhcName :: TH.Name -> CoreM (Maybe Name) thNameToGhcName th_name = do hsc_env <- getHscEnv liftIO $ initTcForLookup hsc_env (lookupThName_maybe th_name) }}} which is not even used in GHC, but only in GHC Plugins, so this could probably be moved to a separate module pulled in by GhcPlugins.hs 2. {{{ import TcEnv ( lookupGlobal ) }}} for {{{ instance MonadThings CoreM where lookupThing name = do { hsc_env <- getHscEnv ; liftIO $ lookupGlobal hsc_env name } }}} This might be a bit harder to disentangle. But if successful, it would probably make building GHC in parallel quite a bit faster. And it just seems strange to me that the Core-to-Core code should depend on the type checker… Simon says: > Both of these code paths go through initTcForLookup which is massive overkill, as the comment with `TcEnv.lookupGlobal` says. There's clearly a ToDo here to strip off the redundant stuff and do a minimal lookup. I am optimistically marking this as `newcomer` because it is a refactoring task, and a good way of learning a bit about various pieces, with a reasonably clear notion of “success”. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14391> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 44

[GHC] #8708: Kind annotation in tuple not parsed
by GHC 04 Oct '18

04 Oct '18

#8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | 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 this: {{{ {-# LANGUAGE KindSignatures #-} foo :: (Int, Int :: *) foo = undefined }}} HEAD reports {{{ /Users/rae/temp/Bug.hs:5:18: parse error on input ‛::’ }}} Changing the line to {{{ foo :: (Int, (Int :: *)) }}} fixes the problem. Note the extra parentheses. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11622: Annotating types in type familiy equations without parentheses
by GHC 04 Oct '18

04 Oct '18

#11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- When annotating types in right-hand side of type family equations parentheses are required: {{{#!hs type family F a where F _ = (Int :: Type) }}} instead of {{{#!hs type family F a where F _ = Int :: Type }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6