Andreas Klebinger pushed to branch wip/andreask/enable_ghci_opt at Glasgow Haskell Compiler / GHC Commits: b8ac3f45 by Andreas Klebinger at 2026-04-29T10:58:56+02:00 Turn -fno-unoptimized-core-for-interpreter off by default. Even if it's still somewhat experimental it's better in most cases now if the execution performance matters. And it's still easy to disable using -O0 Fixes #25955. - - - - - 11 changed files: - + changelog.d/T25955.md - compiler/GHC/Driver/Backend.hs - compiler/GHC/Driver/DynFlags.hs - compiler/GHC/Driver/Session.hs - docs/users_guide/debugging.rst - docs/users_guide/extending_ghc.rst - docs/users_guide/ghci.rst - − testsuite/tests/ghc-api/T10052/T10052.stderr - testsuite/tests/ghci/prog-mhu002/prog-mhu002c.stdout - − testsuite/tests/ghci/should_fail/T10549.stderr - − testsuite/tests/th/T8333.stderr Changes: ===================================== changelog.d/T25955.md ===================================== @@ -0,0 +1,18 @@ +section: ghci +issues: #25955 +mrs: !15773 +synopsis: + Allow optimizations for GHCi by default. +description: + GHCi used to force -O0 because it had no support for certain features + introduced during optimization of programs. E.g. unboxed tuples. + We believe all of those have been addressed now so we can allow -O to take effect + when targeting the bytecode backend/GHCi. + + However there might still be bugs when using -O and the interpreter. + And the simplifier is heavily tuned for targeting the non-bytecode backends + so performance improvements are not a given. + + The old behaviour can be restored by passing `-funoptimized-core-for-interpreter` + to GHC/ghci. + ===================================== compiler/GHC/Driver/Backend.hs ===================================== @@ -20,9 +20,6 @@ especially the driver. Examples include the following: * Property `backendValidityOfCImport` says whether the back end can import foreign C functions. - * Property `backendForcesOptimization0` says whether the back end can - be used with optimization levels higher than `-O0`. - * Property `backendCDefs` tells the compiler driver, "if you're using this back end, then these are the command-line flags you should add to any invocation of the C compiler." @@ -88,7 +85,6 @@ module GHC.Driver.Backend , backendGeneratesHc , backendSptIsDynamic , backendSupportsBreakpoints - , backendForcesOptimization0 , backendNeedsFullWays , backendSupportsHpc , backendSupportsCImport @@ -680,17 +676,6 @@ backendSupportsBreakpoints = \case Named Bytecode -> True Named NoBackend -> False --- | If this flag is set, then the driver forces the --- optimization level to 0, issuing a warning message if --- the command line requested a higher optimization level. -backendForcesOptimization0 :: Backend -> Bool -backendForcesOptimization0 (Named NCG) = False -backendForcesOptimization0 (Named LLVM) = False -backendForcesOptimization0 (Named ViaC) = False -backendForcesOptimization0 (Named JavaScript) = False -backendForcesOptimization0 (Named Bytecode) = True -backendForcesOptimization0 (Named NoBackend) = False - -- | I don't understand exactly how this works. But if -- this flag is set *and* another condition is met, then -- @ghc/Main.hs@ will alter the `DynFlags` so that all the ===================================== compiler/GHC/Driver/DynFlags.hs ===================================== @@ -1229,7 +1229,6 @@ defaultFlags settings Opt_CompactUnwind, Opt_ShowErrorContext, Opt_SuppressStgReps, - Opt_UnoptimizedCoreForInterpreter, Opt_SpecialiseIncoherents, Opt_WriteSelfRecompInfo ] ===================================== compiler/GHC/Driver/Session.hs ===================================== @@ -3819,15 +3819,6 @@ makeDynFlagsConsistent dflags = loop (gopt_set dflags Opt_PIC) "Enabling -fPIC as it is always on for this platform" - | backendForcesOptimization0 (backend dflags) - , gopt Opt_UnoptimizedCoreForInterpreter dflags - , let (dflags', changed) = updOptLevelChanged 0 dflags - , changed - = loop dflags' $ - "Ignoring optimization flags since they are experimental for the " ++ - backendDescription (backend dflags) ++ - ". Pass -fno-unoptimized-core-for-interpreter to enable this feature." - | LinkInMemory <- ghcLink dflags , not (gopt Opt_ExternalInterpreter dflags) , hostIsProfiled ===================================== docs/users_guide/debugging.rst ===================================== @@ -1252,19 +1252,18 @@ Other :type: dynamic :since: 9.8.1 - :default: enabled + :default: disabled - At the moment, ghci disables optimizations, because not all passes - are compatible with the interpreter. - This option can be used to override this check, e.g. - ``ghci -O2 -fno-unoptimized-core-for-interpreter``. - It is not recommended for normal use and can cause a compiler panic. + At the moment, optimizations are used with the interpreter are on by default. + In case this causes errors or compatibility issues this option can be used to override + the behaviour, e.g. + ``ghci -O2 -funoptimized-core-for-interpreter``. Note that this has an effect on the debugger interface: With optimizations in play, free variables in breakpoints may now be substituted with complex - expressions. - Those cannot be stored in breakpoints, so any free variable that refers to - optimized code will not be inspectable when this flag is enabled. + expressions. This means disabling optimizations can improve the debugging experience. + As otherwise those variables cannot be stored in breakpoints, so any free variable that refers to + optimized code will not be inspectable when this flag is disabled. .. ghc-flag:: -fadd-bco-name :shortdesc: Add ``BCO_NAME`` instructions in generated bytecode. ===================================== docs/users_guide/extending_ghc.rst ===================================== @@ -1750,10 +1750,10 @@ decision-making code depends on the code’s form. - If your decision-making is driven by an equality or inequality predicate, an equivalent predicate may already be defined in module ``GHC.Driver.Backend``. For example, if your client wants to be - sure that optimization levels above ``-O0`` are permitted, it might - have originally compared ``backend /= Interpreter``. But now there is + sure that breakpoints are supported, it might + have originally compared ``backend == Interpreter``. But now there is a predicate for that: it is - ``not (backendForcesOptimization0 backend)``. + ``backendSupportsBreakpoints backend``. If the predicate you want is not already defined, you will have to fall back on the more general strategy defined below. ===================================== docs/users_guide/ghci.rst ===================================== @@ -3678,7 +3678,7 @@ The interpreter can't load modules with foreign export declarations! Unfortunately not. We haven't implemented it yet. Please compile any offending modules by hand before loading them into GHCi. -:ghc-flag:`-O` is ineffective in GHCi! +:ghc-flag:`-O` is experimental in GHCi! .. index:: single: optimization; and GHCi @@ -3686,11 +3686,12 @@ The interpreter can't load modules with foreign export declarations! Before GHC 9.8, optimizations were considered too unstable to be used with the bytecode interpreter. This restriction has been lifted, but is still regarded as experimental and - guarded by :ghc-flag:`-funoptimized-core-for-interpreter`, which is enabled - by default. - In order to use optimizations, run: :: + guarded by :ghc-flag:`-funoptimized-core-for-interpreter`. Starting with + 10.0 it is enabled by default. - ghci -fno-unoptimized-core-for-interpreter -O + If this causes issue you can disable it by using: :: + + ghci -funoptimized-core-for-interpreter -O Concurrent threads don't carry on running when GHCi is waiting for input. This should work, as long as your GHCi was built with the ===================================== testsuite/tests/ghc-api/T10052/T10052.stderr deleted ===================================== @@ -1,3 +0,0 @@ - -when making flags consistent: warning: [GHC-74335] [-Winconsistent-flags] - Ignoring optimization flags since they are experimental for the byte-code interpreter. Pass -fno-unoptimized-core-for-interpreter to enable this feature. ===================================== testsuite/tests/ghci/prog-mhu002/prog-mhu002c.stdout ===================================== @@ -11,7 +11,6 @@ other dynamic, non-language, flag settings: -fignore-hpc-changes -fno-ghci-history -fimplicit-import-qualified - -fno-unoptimized-core-for-interpreter -fshow-warning-groups -fprefer-byte-code -fbreak-points @@ -30,7 +29,6 @@ other dynamic, non-language, flag settings: -fignore-hpc-changes -fno-ghci-history -fimplicit-import-qualified - -fno-unoptimized-core-for-interpreter -fshow-warning-groups -fprefer-byte-code -fbreak-points @@ -47,7 +45,6 @@ other dynamic, non-language, flag settings: -fignore-hpc-changes -fno-ghci-history -fimplicit-import-qualified - -fno-unoptimized-core-for-interpreter -fshow-warning-groups -fprefer-byte-code -fbreak-points @@ -64,7 +61,6 @@ other dynamic, non-language, flag settings: -fignore-hpc-changes -fno-ghci-history -fimplicit-import-qualified - -fno-unoptimized-core-for-interpreter -fshow-warning-groups -fprefer-byte-code -fbreak-points @@ -81,7 +77,6 @@ other dynamic, non-language, flag settings: -fignore-hpc-changes -fno-ghci-history -fimplicit-import-qualified - -fno-unoptimized-core-for-interpreter -fshow-warning-groups -fprefer-byte-code -fbreak-points ===================================== testsuite/tests/ghci/should_fail/T10549.stderr deleted ===================================== @@ -1,3 +0,0 @@ - -when making flags consistent: warning: [GHC-74335] [-Winconsistent-flags (in -Wdefault)] - Ignoring optimization flags since they are experimental for the byte-code interpreter. Pass -fno-unoptimized-core-for-interpreter to enable this feature. ===================================== testsuite/tests/th/T8333.stderr deleted ===================================== @@ -1,3 +0,0 @@ - -when making flags consistent: warning: [GHC-74335] [-Winconsistent-flags (in -Wdefault)] - Ignoring optimization flags since they are experimental for the byte-code interpreter. Pass -fno-unoptimized-core-for-interpreter to enable this feature. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b8ac3f45a2e329c7b52f474137e3a09c... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b8ac3f45a2e329c7b52f474137e3a09c... You're receiving this email because of your account on gitlab.haskell.org.