@simonpj observed in #25066 that the backtrace collection logic introduced in #199 has resulted in a rather subtle regression in the demand signature inferred for the throw operation. Specifically, the pure throw function, due to a rather delicate cascade of optimisations involving unsafePerformIO, is now considered by GHC's demand analyzer to potentially diverge with a precise exception (N.B. I have described the precise reasoning in Note [Hiding precise exception signature in throw] in the implementation, !13275). As GHC must tread carefully when optimising around functions terminating with precise exceptions this constitutes a runtime performance regression on the order of 1%.
Sadly we do not currently have a principled means in GHC to control the propagation of precise exceptions through across unsafePerformIO. However, we can avoid the simplification leading to this regression with a judicious use of GHC.Exts.noinline:
diff --git a/libraries/ghc-internal/src/GHC/Internal/Exception.hs b/libraries/ghc-internal/src/GHC/Internal/Exception.hs
index 50005ba363c..dba92921b34 100644
--- a/libraries/ghc-internal/src/GHC/Internal/Exception.hs
+++ b/libraries/ghc-internal/src/GHC/Internal/Exception.hs
@@ -81,9 +81,86 @@ import GHC.Internal.Exception.Type
throw :: forall (r :: RuntimeRep). forall (a :: TYPE r). forall e.
(HasCallStack, Exception e) => e -> a
throw e =
- let !se = unsafePerformIO (toExceptionWithBacktrace e)
+ let !se = noinline (unsafePerformIO (toExceptionWithBacktrace e))
in raise# seThis gives up a small bit of optimisation in the body of throw (which is used only in cold, erroring codepaths) in exchange for considerably better optimisation at use-sites. Specifically, the use of noinline prevents unsafePerformIO from being inlined, in turn preventing the raise# application from being floated into the runRW# continuation it contains, ensuring that the demand analysers' divergence heuristics do not conclude that the the runRW# might throw a precise exception. This should have no effect on the types or semantics observed by the end-user, but will make their program a bit faster.
Note that this is a temporary measure which we propose to use for GHC 9.10 and 9.12. We hope that by 9.14 we might have a set of primops to more explicitly control the demand analyser's divergence heuristics, allowing us to again allow inlining.
@simonpj observed in #25066 that the backtrace collection logic introduced in #199 has resulted in a rather subtle regression in the demand signature inferred for the
throwoperation. Specifically, the purethrowfunction, due to a rather delicate cascade of optimisations involvingunsafePerformIO, is now considered by GHC's demand analyzer to potentially diverge with a precise exception (N.B. I have described the precise reasoning inNote [Hiding precise exception signature in throw]in the implementation, !13275). As GHC must tread carefully when optimising around functions terminating with precise exceptions this constitutes a runtime performance regression on the order of 1%.Sadly we do not currently have a principled means in GHC to control the propagation of precise exceptions through across
unsafePerformIO. However, we can avoid the simplification leading to this regression with a judicious use ofGHC.Exts.noinline:This gives up a small bit of optimisation in the body of
throw(which is used only in cold, erroring codepaths) in exchange for considerably better optimisation at use-sites. Specifically, the use ofnoinlinepreventsunsafePerformIOfrom being inlined, in turn preventing theraise#application from being floated into therunRW#continuation it contains, ensuring that the demand analysers' divergence heuristics do not conclude that the therunRW#might throw a precise exception. This should have no effect on the types or semantics observed by the end-user, but will make their program a bit faster.Note that this is a temporary measure which we propose to use for GHC 9.10 and 9.12. We hope that by 9.14 we might have a set of primops to more explicitly control the demand analyser's divergence heuristics, allowing us to again allow inlining.