diff options
author | Matthew Pickering <matthewtpickering@gmail.com> | 2022-10-01 18:16:20 +0100 |
---|---|---|
committer | Marge Bot <ben+marge-bot@smart-cactus.org> | 2022-10-11 12:48:45 -0400 |
commit | e058b138fef9f697095f97cb6a52f6ba58c940c5 (patch) | |
tree | ad00ed929ee6d5fa69825c00d1b8ff3d3dd9ee14 /ghc | |
parent | fbb887406d27b5271e45392c2c25f8b1ba4cdeae (diff) | |
download | haskell-e058b138fef9f697095f97cb6a52f6ba58c940c5.tar.gz |
Interface Files with Core Definitions
This commit adds three new flags
* -fwrite-if-simplified-core: Writes the whole core program into an interface
file
* -fbyte-code-and-object-code: Generate both byte code and object code
when compiling a file
* -fprefer-byte-code: Prefer to use byte-code if it's available when
running TH splices.
The goal for including the core bindings in an interface file is to be able to restart the compiler pipeline
at the point just after simplification and before code generation. Once compilation is
restarted then code can be created for the byte code backend.
This can significantly speed up
start-times for projects in GHCi. HLS already implements its own version of these extended interface
files for this reason.
Preferring to use byte-code means that we can avoid some potentially
expensive code generation steps (see #21700)
* Producing object code is much slower than producing bytecode, and normally you
need to compile with `-dynamic-too` to produce code in the static and dynamic way, the
dynamic way just for Template Haskell execution when using a dynamically linked compiler.
* Linking many large object files, which happens once per splice, can be quite
expensive compared to linking bytecode.
And you can get GHC to compile the necessary byte code so
`-fprefer-byte-code` has access to it by using
`-fbyte-code-and-object-code`.
Fixes #21067
Diffstat (limited to 'ghc')
-rw-r--r-- | ghc/GHCi/Leak.hs | 11 | ||||
-rw-r--r-- | ghc/Main.hs | 5 |
2 files changed, 13 insertions, 3 deletions
diff --git a/ghc/GHCi/Leak.hs b/ghc/GHCi/Leak.hs index e99ff405aa..51e3958ba2 100644 --- a/ghc/GHCi/Leak.hs +++ b/ghc/GHCi/Leak.hs @@ -22,6 +22,7 @@ import Prelude import System.Mem import System.Mem.Weak import GHC.Types.Unique.DFM +import Control.Exception -- Checking for space leaks in GHCi. See #15111, and the -- -fghci-leak-check flag. @@ -32,7 +33,7 @@ data LeakModIndicators = LeakModIndicators { leakMod :: Weak HomeModInfo , leakIface :: Weak ModIface , leakDetails :: Weak ModDetails - , leakLinkable :: Maybe (Weak Linkable) + , leakLinkable :: [Maybe (Weak Linkable)] } -- | Grab weak references to some of the data structures representing @@ -44,8 +45,12 @@ getLeakIndicators hsc_env = leakMod <- mkWeakPtr hmi Nothing leakIface <- mkWeakPtr hm_iface Nothing leakDetails <- mkWeakPtr hm_details Nothing - leakLinkable <- mapM (`mkWeakPtr` Nothing) hm_linkable + leakLinkable <- mkWeakLinkables hm_linkable return $ LeakModIndicators{..} + where + mkWeakLinkables :: HomeModLinkable -> IO [Maybe (Weak Linkable)] + mkWeakLinkables (HomeModLinkable mbc mo) = + mapM (\ln -> traverse (flip mkWeakPtr Nothing <=< evaluate) ln) [mbc, mo] -- | Look at the LeakIndicators collected by an earlier call to -- `getLeakIndicators`, and print messasges if any of them are still @@ -63,7 +68,7 @@ checkLeakIndicators dflags (LeakIndicators leakmods) = do Nothing -> return () Just miface -> report ("ModIface:" ++ moduleNameString (moduleName (mi_module miface))) (Just miface) deRefWeak leakDetails >>= report "ModDetails" - forM_ leakLinkable $ \l -> deRefWeak l >>= report "Linkable" + forM_ leakLinkable $ \l -> forM_ l $ \l' -> deRefWeak l' >>= report "Linkable" where report :: String -> Maybe a -> IO () report _ Nothing = return () diff --git a/ghc/Main.hs b/ghc/Main.hs index 45dd5fede1..16075284c0 100644 --- a/ghc/Main.hs +++ b/ghc/Main.hs @@ -209,6 +209,11 @@ main' postLoadMode units dflags0 args flagWarnings = do where def_ghci_flags = dflags1 `gopt_set` Opt_ImplicitImportQualified `gopt_set` Opt_IgnoreOptimChanges `gopt_set` Opt_IgnoreHpcChanges + -- Setting this by default has the nice effect that + -- -fno-code and --interactive falls back to interpreter rather than + -- object code but has little other effect unless you are also using + -- fat interface files. + `gopt_set` Opt_UseBytecodeRatherThanObjects logger1 <- getLogger let logger2 = setLogFlags logger1 (initLogFlags dflags2) |