- ghc-tickets - Haskell.org

Re: [GHC] #4962: Dead code fed to CorePrep because RULEs keep it alive spuriously
by GHC 21 Mar '13

21 Mar '13

#4962: Dead code fed to CorePrep because RULEs keep it alive spuriously --------------------------------------+------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Compiler | Version: 7.0.1 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > This ticket is split off from #4941. > > I'm seeing output code that looks roughly like this in the final > simplifier output: > > {{{ > let > {-# RULES go (Just x) = $sgo_s1lg x #-} > go = ... go ... $w$sgo ... > $sgo_s1lg = ... $w$sgo_s1mv ... > $w$sgo_s1mv = ... big ... > in ... $w$sgo_s1mv ... > }}} > > This is bad because $sgo is will be dead for the purposes of code > generation, but currently GHC will allocate a closure for it at runtime > anyway. > > What we should do is drop the dead binding once we have decided that it's > not reachable via the exported RULES in the interface file. > > I've confirmed that this patch achieves this effect (and eliminates the > main source of increased allocations I was seeing in #4941): > > {{{ > hunk ./compiler/main/TidyPgm.lhs 22 > +import OccurAnal ( occurAnalysePgm ) > hunk ./compiler/main/TidyPgm.lhs 43 > +import qualified ErrUtils as Err > hunk ./compiler/main/TidyPgm.lhs 47 > +import PprCore > hunk ./compiler/main/TidyPgm.lhs 322 > + > + -- Occurrence analyse the input program, assuming all local > rules are off, > + -- but retaining any bindings referred to by external rules. > + -- Occurrence information may have improved since the last run > of the > + -- simplifier because some bindings will become dead once > RULES are dropped. > + -- > + -- The analysis itself will take care of dropping any newly- > dead syntax. > + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "BEFORE TidyPgm > occurrence analysis" (pprCoreBindings binds) > + ; binds <- return $ occurAnalysePgm Nothing ext_rules binds > + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "TidyPgm > occurrence analysis" (pprCoreBindings binds) > + > hunk ./compiler/simplCore/OccurAnal.lhs 393 > - rule_fvs = idRuleVars bndr -- See Note [Rule > dependency info] > + rule_fvs = case occ_rule_act env of Nothing -> emptyVarSet; > Just _ -> idRuleVars bndr -- See Note [Rule dependency info] > + -- FIXME: this is a terrible hack to try to have OccAnal drop > bindings that are kept alive only due to rules at the CoreTidy stage > }}} > > However the patch is a bit horrible: because attached RULES keep bindings > alive in a LetRec even if the rules can never be activated (i.e. > occ_rule_act env == Nothing) the bindings I want to be dropped never get > dropped. The reason I consider my fix a hack is that just because the > rules are inactive *now* doesn't mean that they will be inactive *later*. > > A better approach would perhaps be to wait until the RULES are stripped > from the binders entirely (e.g. OccAnal the output of CoreTidy). However, > this is not straightforward because CoreTidy has globalised Ids, so > OccAnaling the output says that all top level bindings have no FVs and > hence turns all LetRecs into Lets! New description: This ticket is split off from #4941. I'm seeing output code that looks roughly like this in the final simplifier output: {{{ let {-# RULES go (Just x) = $sgo_s1lg x #-} go = ... go ... $w$sgo ... $sgo_s1lg = ... $w$sgo_s1mv ... $w$sgo_s1mv = ... big ... in ... $w$sgo_s1mv ... }}} This is bad because $sgo is will be dead for the purposes of code generation, but currently GHC will allocate a closure for it at runtime anyway. What we should do is drop the dead binding once we have decided that it's not reachable via the exported RULES in the interface file. I've confirmed that this patch achieves this effect (and eliminates the main source of increased allocations I was seeing in #4941): {{{ hunk ./compiler/main/TidyPgm.lhs 22 +import OccurAnal ( occurAnalysePgm ) hunk ./compiler/main/TidyPgm.lhs 43 +import qualified ErrUtils as Err hunk ./compiler/main/TidyPgm.lhs 47 +import PprCore hunk ./compiler/main/TidyPgm.lhs 322 + + -- Occurrence analyse the input program, assuming all local rules are off, + -- but retaining any bindings referred to by external rules. + -- Occurrence information may have improved since the last run of the + -- simplifier because some bindings will become dead once RULES are dropped. + -- + -- The analysis itself will take care of dropping any newly- dead syntax. + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "BEFORE TidyPgm occurrence analysis" (pprCoreBindings binds) + ; binds <- return $ occurAnalysePgm Nothing ext_rules binds + ; Err.dumpIfSet_dyn dflags Opt_D_dump_occur_anal "TidyPgm occurrence analysis" (pprCoreBindings binds) + hunk ./compiler/simplCore/OccurAnal.lhs 393 - rule_fvs = idRuleVars bndr -- See Note [Rule dependency info] + rule_fvs = case occ_rule_act env of Nothing -> emptyVarSet; Just _ -> idRuleVars bndr -- See Note [Rule dependency info] + -- FIXME: this is a terrible hack to try to have OccAnal drop bindings that are kept alive only due to rules at the CoreTidy stage }}} However the patch is a bit horrible: because attached RULES keep bindings alive in a !LetRec even if the rules can never be activated (i.e. occ_rule_act env == Nothing) the bindings I want to be dropped never get dropped. The reason I consider my fix a hack is that just because the rules are inactive *now* doesn't mean that they will be inactive *later*. A better approach would perhaps be to wait until the RULES are stripped from the binders entirely (e.g. !OccAnal the output of !CoreTidy). However, this is not straightforward because !CoreTidy has globalised Ids, so OccAnaling the output says that all top level bindings have no FVs and hence turns all !LetRecs into Lets! -- -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4962#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7754: Can't find curses.h when building cross-compiler
by GHC 21 Mar '13

21 Mar '13

#7754: Can't find curses.h when building cross-compiler --------------------------------+------------------------------------------- Reporter: fumieval | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: arm, terminfo, raspberry pi Os: Linux | Architecture: arm Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- {{{ $ PATH=$PATH:/home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin $ ./configure --target=arm-linux-gnueabihf --enable-unregisterised $ make (...) "inplace/bin/ghc-cabal" check libraries/terminfo "inplace/bin/ghc-cabal" configure --with- ghc="/home/fumiaki/ghc/inplace/bin/ghc-stage1" --with-ghc- pkg="/home/fumiaki/ghc/inplace/bin/ghc-pkg" --enable-library-vanilla --disable-library-profiling --disable-shared --disable-library-for-ghci --enable-library-for-ghci --with- hscolour="/home/fumiaki/.cabal/bin/HsColour" --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --configure-option=--host=arm-unknown-linux-gnueabihf --with- gcc="/home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf- raspbian/bin/arm-linux-gnueabihf-gcc" --with-ld="/home/fumiaki/tools/arm- bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- ld" --configure-option=--with-cc="/home/fumiaki/tools/arm-bcm2708/gcc- linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc" --with- ar="/usr/bin/ar" --with-ranlib="true" --with- alex="/home/fumiaki/.cabal/bin/alex" --with- happy="/home/fumiaki/.cabal/bin/happy" -- dist-install libraries/terminfo Configuring terminfo-0.3.2.5... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking for arm-unknown-linux-gnueabihf-gcc... /home/fumiaki/tools/arm- bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc accepts -g... yes checking for /home/fumiaki/tools/arm-bcm2708/gcc-linaro-arm-linux- gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /home/fumiaki/tools/arm-bcm2708 /gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/home/fumiaki/ghc/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} Of course there are curses.h and corresponding library which is installed by 'apt-get install libncurses5-dev'. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4941: SpecConstr generates functions that do not use their arguments
by GHC 21 Mar '13

21 Mar '13

#4941: SpecConstr generates functions that do not use their arguments ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): Replying to [comment:20 nfrisby]: > I'm investigating nucleic2 at the moment; it's changing something currently not specifically tracked by ticky, so I'm resurrecting more counters. There's nothing obvious to me in the STG, at least. It's actually pretty clear in the STG. A let at the entry to $w$wvar_most_distant_atom with 12 free Float# vars gets inlined into numerous thunks, at least 24 (25?) of which are allocated all at once. In the CMM `Hp = Hp + 1376` becomes `Hp = Hp + 3576`. Some arithmetic with these numbers just about covers the reported ticky difference for $w$wvar_most_distant_atom. Needs more inspection (distinct from this ticket... sorry), though this seems a bit of a corner case: arity=40 and the involved state type uses record types with numerous non-strict fields of type Float. I'll record it with the ticket I'm soon making for the late demand analysis pass. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4941#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7781: Dumb error message when trying to runghc a module with no 'main' function
by GHC 21 Mar '13

21 Mar '13

#7781: Dumb error message when trying to runghc a module with no 'main' function -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- $ runghc Log.hs Log.hs:1:33: Not in scope: `main' Perhaps you meant `min' (imported from Prelude) It really should say something like: No `main` function found. Can't run a module with no `main'. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 21 Mar '13

21 Mar '13

#4837: Template Haskell does not work in a profiled compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Profiling | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Old description: > Template Haskell does not work if the compiler itself is built profiles. > Because of this we cannot debug GHC compile time performance problems > when compiling Data.Vector and DPH as they use Template Haskell. #4172 is > related. > > Trying to use Template Haskell in a profiled compiler currently triggers > the assertion at {{{main/HscMain.hs:1245}}} New description: Template Haskell does not work if the compiler itself is built profiles. Because of this we cannot debug GHC compile time performance problems when compiling Data.Vector and DPH as they use Template Haskell. #4172 is related. Trying to use Template Haskell in a profiled compiler currently triggers the assertion at {{{main/HscMain.hs:1245}}} Supporting this would also mean that we can run GHCi with profiled code! -- Comment(by ezyang): OK, I added a note to the description mentioning GHCi would also benefit from this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4837#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 20 Mar '13

20 Mar '13

#4837: Template Haskell does not work in a profiled compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Profiling | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: closed #3360 as a dup. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4837#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3360: Add profiling support to GHCi
by GHC 20 Mar '13

20 Mar '13

#3360: Add profiling support to GHCi -------------------------------+-------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.2 Resolution: duplicate | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Closing as dup of #4837 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3360#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7743: GHCI segfaults with Data.Binary instances
by GHC 20 Mar '13

20 Mar '13

#7743: GHCI segfaults with Data.Binary instances -----------------------------+---------------------------------------------- Reporter: BigEndian | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHCi crash | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The following code seems to crash GHCi I apologize for the long test case, but I'll need to rebuild ghc with symbols first before I can reduce the test case. GHCi's output is {{{ eric@sagacity ~/prog/haskell/tasks master > ghci GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :l Segfault.hs [1 of 1] Compiling Main ( Segfault.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package binary-0.5.1.1 ... linking ... done. "zsh: segmentation fault ghci }}} Related code is {{{ module Main where import qualified Data.ByteString as BW import Data.Word(Word8(..)) import Data.Binary import Control.Monad import Data.Char convertWord8ToChar :: Word8 -> Char convertWord8ToChar = chr . fromIntegral convertCharToWord8 :: Char -> Word8 convertCharToWord8 = fromIntegral . ord stringToWByteString :: String -> BW.ByteString stringToWByteString = BW.pack . map convertCharToWord8 wByteStringToString :: BW.ByteString -> String wByteStringToString = map convertWord8ToChar . BW.unpack newtype TaskString = TaskString BW.ByteString deriving (Read, Show) stringToTaskString :: String -> TaskString stringToTaskString = TaskString . stringToWByteString word8sToTaskString :: [Word8] -> TaskString word8sToTaskString = TaskString . BW.pack instance Binary TaskString where get = do (return . word8sToTaskString . init) =<< readWord8sUntil 0 where readWord8sUntil :: Word8 -> Get [Word8] readWord8sUntil val = do w8 <- getWord8 if w8 == val then return $ [w8] else (return . (w8:)) =<< (readWord8sUntil val) put (TaskString bws) = mapM_ putWord8 $ (BW.unpack bws) ++ [0] data Task = Task { taskTitle :: TaskString, taskNotes :: TaskString, taskPriority :: Int } deriving (Read, Show) instance Binary Task where get = do tt <- get :: Get TaskString tn <- get :: Get TaskString tp <- get :: Get Int return Task { taskTitle = tt, taskNotes = tn, taskPriority = tp } put t = do put $ taskTitle t put $ taskNotes t put $ taskPriority t exTaskTitle = stringToTaskString "Do the dishes" exTaskNotes = stringToTaskString "Must be done by 12:00 today" exTaskPriority = 0 encTaskTitle = encode exTaskTitle decTaskTitle = decode encTaskTitle :: TaskString exTask = Task { taskTitle = exTaskTitle, taskNotes = exTaskNotes, taskPriority = exTaskPriority } encTask = encode exTask decTask = decode encTask :: Task main = do putStrLn $ show encTask -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4837: Template Haskell does not work in a profiled compiler.
by GHC 20 Mar '13

20 Mar '13

#4837: Template Haskell does not work in a profiled compiler. ---------------------------------+------------------------------------------ Reporter: benl | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Profiling | Version: 7.0.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC doesn't work at all Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by ezyang): #3360 seems related? I'm not sure what the difference here is. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4837#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 20 Mar '13

20 Mar '13

#5302: Unused arguments in join points ---------------------------------+------------------------------------------ Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by nfrisby): As of 321941a, this test case (at less the _full.hs one) still generates the unused arguments. In fact, the join point under discussion also contains a join point with the same flaw. This happens with and without a SpecConstr. In both cases, a late demand analysis removes both unnecessary arguments. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5302#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0