Andreas Klebinger pushed to branch wip/apk/expose-overloaded-unfoldings at Glasgow Haskell Compiler / GHC Commits: b1eb8241 by Andreas Klebinger at 2026-09-15T14:53:55+02:00 Enable -fexpose-overloaded-unfoldings by default when optimizations are on. - - - - - 4 changed files: - + changelog.d/T13090-expose-overloaded-unfoldings - compiler/GHC/Driver/DynFlags.hs - compiler/GHC/Iface/Tidy.hs - docs/users_guide/using-optimisation.rst Changes: ===================================== changelog.d/T13090-expose-overloaded-unfoldings ===================================== @@ -0,0 +1,6 @@ +section: compiler +issues: #13090 +mrs: !16684 +synopsis: + Enable :ghc-flag:`-fexpose-overloaded-unfoldings` by default with :ghc-flag:`-O` or higher. + ===================================== compiler/GHC/Driver/DynFlags.hs ===================================== @@ -1337,6 +1337,7 @@ optLevelFlags -- see Note [Documenting optimisation flags] , ([1,2], Opt_Specialise) , ([1,2], Opt_PolymorphicSpecialisation) -- Now on by default (#23559) , ([1,2], Opt_CrossModuleSpecialise) + , ([1,2], Opt_ExposeOverloadedUnfoldings) -- See Note [Exposing overloaded functions] in GHC.Iface.Tidy , ([1,2], Opt_InlineGenerics) , ([1,2], Opt_Strictness) , ([1,2], Opt_UnboxSmallStrictFields) ===================================== compiler/GHC/Iface/Tidy.hs ===================================== @@ -806,8 +806,19 @@ anyway we allow for some false positives and simply expose all functions which have a constraint. This means we might expose more unhelpful unfoldings. But it seems like the better choice. -Currently this option is off by default and has to be enabled manually. But -we might change this in the future. +We enable the flag by default with -O/O2 to allow users to opt into specialization +at call sites. We do not enable -fspecialize-aggressively. See also #13090. + +In terms of performance impact the cost is very modest: +On GHC and it's boot libraries overall enabling this flag increases overall disk +space used by ~1%. With a highly variant distribution across various .hi files. +In terms of compile times the overhead is low enough to be hard to measure, but +seemed to be less than 0.2% if anything at all. + +It seems tempting to do the same for -fspecialize-aggressively, but that comes in +at a hefty 20% compile time overhead. So we only provide the unfoldings and leave +the choice of how much specialization to enable up to the user. + -} {- ===================================== docs/users_guide/using-optimisation.rst ===================================== @@ -624,10 +624,10 @@ as such you shouldn't need to set any of them explicitly. A flag :reverse: -fno-expose-overloaded-unfoldings :category: - :default: off + :default: -O and above :since: 9.12.1 - This experimental flag is a slightly less heavy weight alternative + This flag is a slightly less heavy weight alternative to :ghc-flag:`-fexpose-all-unfoldings`. Instead of exposing all functions it exposes only those functions which View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b1eb8241e455377551bba1c3c889ae4e... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b1eb8241e455377551bba1c3c889ae4e... You're receiving this email because of your account on gitlab.haskell.org. Manage all notifications: https://gitlab.haskell.org/-/profile/notifications | Help: https://gitlab.haskell.org/help